httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony J. Biacco" <abia...@formatdynamics.com>
Subject RE: [users@httpd] cache POST requests
Date Tue, 10 Feb 2009 22:04:52 GMT
In those respects, then I would concur. It was in that the application server can choose not
to honor the predictability of the GET and change data or send different data back instead,
is what tripped my mind up. Was much simpler years and years ago when you were just GETing
static files from the web servers. I looked at it deeper down than the generalizations, the
spirit (if you will) of GET and POST. That was probably my undoing.
Thank you.

-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x27
abiacco@formatdynamics.com
http://www.formatdynamics.com


-----Original Message-----
From: André Warnier [mailto:aw@ice-sa.com] 
Sent: Tuesday, February 10, 2009 2:44 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] cache POST requests

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


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


Mime
View raw message