You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "Anthony J. Biacco" <ab...@formatdynamics.com> on 2009/02/10 19:34:34 UTC
[users@httpd] cache POST requests
Hello,
I'm using apache 2.2.11 on centos 5/x86_64
I'm testing out caching data for GET requests using mod_disk_cache,
which I have working.
I'd also like to cache data for the same requests via the POST method,
but this doesn't seem to work.
Is this supported? If so, is there any config changes required for this
to work? If not, is this feature planned?
Thanx,
-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x27
abiacco@formatdynamics.com
http://www.formatdynamics.com
---------------------------------------------------------------------
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
RE: [users@httpd] cache POST requests
Posted by "Anthony J. Biacco" <ab...@formatdynamics.com>.
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
Re: [users@httpd] cache POST requests
Posted by André Warnier <aw...@ice-sa.com>.
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
RE: [users@httpd] cache POST requests
Posted by "Anthony J. Biacco" <ab...@formatdynamics.com>.
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.
-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 12:39 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] cache POST requests
Anthony J. Biacco wrote:
> Hello,
>
> I'm using apache 2.2.11 on centos 5/x86_64
> I'm testing out caching data for GET requests using mod_disk_cache,
> which I have working.
> I'd also like to cache data for the same requests via the POST method,
> but this doesn't seem to work.
> Is this supported? If so, is there any config changes required for this
> to work? If not, is this feature planned?
>
Hi.
Let me refer you to the following document :
http://www.ietf.org/rfc/rfc2616.txt
(that is the official definition of the HTTP protocol, and how it works).
Really. Seriously. I am not pulling your leg. I guarantee that if you
read it seriously, you would not need to ask the question above, because
you would understand why it does not make sense.
Check section 9, which explains the various methods such as GET and
POST, and their differences.
In short, it explains that GET is a method that is "idempotent", and
POST is not.
In normal language, it means that when you do a GET, and then you do the
same GET again, it should give you the same response. That is what is
meant by "idem potent".
(Typical usage : a search in a database)
On the other hand, a POST means that the information you send in the
POST, can modify something on the server. Which means that after you do
a POST, the server may "not be the same" anymore. So if you re-do the
same POST, the answer may be different, because your first POST will
have changed something on the server.
(Typical usage : do some "data entry" on the server)
That is why it makes sense to cache the results of a GET : since in
principle doing the same GET later would give you the same response
anyway, then why not cache it, and avoid asking for the same response
again ?
But a POST is another animal. There would be little point in caching
the response, because the next time you make the same POST request, in
principle the response will be different, so there is no point in
caching the previous one.
Many people think that the difference between a GET and a POST is how
the paremeters are passed to the server. That is not true at all. Both
can pass the parameters in two ways, the same two ways for both.
The difference is not in how you pass the values to the server. The
difference is in what you expect your request to do at the server side.
In other words, the simple answer to your question is : No.
No browser, no webserver, no proxy server will nor should /ever/ cache
the response to a POST. It would be contrary to the HTTP specification.
---------------------------------------------------------------------
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
Re: [users@httpd] cache POST requests
Posted by André Warnier <aw...@ice-sa.com>.
Anthony J. Biacco wrote:
> Hello,
>
> I'm using apache 2.2.11 on centos 5/x86_64
> I'm testing out caching data for GET requests using mod_disk_cache,
> which I have working.
> I'd also like to cache data for the same requests via the POST method,
> but this doesn't seem to work.
> Is this supported? If so, is there any config changes required for this
> to work? If not, is this feature planned?
>
Hi.
Let me refer you to the following document :
http://www.ietf.org/rfc/rfc2616.txt
(that is the official definition of the HTTP protocol, and how it works).
Really. Seriously. I am not pulling your leg. I guarantee that if you
read it seriously, you would not need to ask the question above, because
you would understand why it does not make sense.
Check section 9, which explains the various methods such as GET and
POST, and their differences.
In short, it explains that GET is a method that is "idempotent", and
POST is not.
In normal language, it means that when you do a GET, and then you do the
same GET again, it should give you the same response. That is what is
meant by "idem potent".
(Typical usage : a search in a database)
On the other hand, a POST means that the information you send in the
POST, can modify something on the server. Which means that after you do
a POST, the server may "not be the same" anymore. So if you re-do the
same POST, the answer may be different, because your first POST will
have changed something on the server.
(Typical usage : do some "data entry" on the server)
That is why it makes sense to cache the results of a GET : since in
principle doing the same GET later would give you the same response
anyway, then why not cache it, and avoid asking for the same response
again ?
But a POST is another animal. There would be little point in caching
the response, because the next time you make the same POST request, in
principle the response will be different, so there is no point in
caching the previous one.
Many people think that the difference between a GET and a POST is how
the paremeters are passed to the server. That is not true at all. Both
can pass the parameters in two ways, the same two ways for both.
The difference is not in how you pass the values to the server. The
difference is in what you expect your request to do at the server side.
In other words, the simple answer to your question is : No.
No browser, no webserver, no proxy server will nor should /ever/ cache
the response to a POST. It would be contrary to the HTTP specification.
---------------------------------------------------------------------
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