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-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org