Anthony J. Biacco wrote:
I did in fact read the rfc before I posted, but it seems to me that once you're doing proxying to an application server, these facts don't apply anymore. I could be way off base. But a GET proxied to an application server doesn't have to, and (depending on how the webapp is designed) doesn't return the same response, based on the state of the application server (and anything behind it). And in turn, a POST can return the same response to the same POST request..that is of course (for the POST) if you don't take just the URI into account, but the whole request (i.e. keys and values). Please correct me if I'm misunderstanding. Perhaps the rfc just isn't taking in account application servers (and perhaps shouldn't)..or I'm an idiot. One of the two.
Well at least you're humble, and accept the idea that you might be. ;-)You're obviously not, since at least you bothered to read the RFC. A lot of people don't.
I believe the point is that by using GET and POST indiscriminately, a client runs the risk of confusing the server, particularly in the case of an error somewhere. I'll take your example of an intermediate "proxy" server. It receives a GET request from a client, and issues a request to a back-end server to obtain the response (this back-end server not necessarily being a HTTP server). For some reason, the back-end server takes more time to respond than planned, hitting some timeout. If the request was a GET, the proxy server could feel perfectly justified in retrying the request, in that the request should be "idempotent". However, if the request was a POST, it should not feel so confident, because the use of a POST clearly indicates (if the intent of the RFC is respected) that the first request, if it has gone through, may have modified the information on the back-end server, and that retrying it may now place a second irrevocable order for a corporate jet.
By respecting the intent of the RFC, the client is in fact gaining an advantage of predictability. Just by choosing between a GET and a POST, it can decide if the server is or not allowed to retry the request in case of (some kinds of) failure. The client gains, because it can rely on reputable webservers like Apache to respect the RFC. (One wishes that it would be the same on the server side, and that server applications could make the same assumption about clients).
When the choice of method is made, the client can decide, independently of the method, if it sends the query parameters (or data) of the request in either the URL-encoded format (appended to the URL) or the multipart/form-data format (in the request body). Both work with GET as well as POST. And as long as you are in the mood to read specs, here is more information about that :
http://www.w3.org/TR/html4/interact/forms.html#form-data-set --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|