> Also becomes more of a problem when my page's JS would have to know for subsequent requests how to get the cached version, and not simply do a PRG again, because it would not know if a cached version existed.
Just check for the existence of a file with the matching date and hash. If it's missing, Apacher will display a 404 for you. > Even if I sent a probing GET request pre-all reformatting requests, the JS would not have the hash. Unnecessary, your hash should be inside the GET URL itself. Including a SHA1sum and date into the URL should easily fit within 2k without any difficulty. > And now I'd be doing 3 requests for every 1 I was doing beforehand. Only two requests needed, but if you had a connection reset of something more than halfway through, you could save bandwidth, as GET supports range based retrievals and you don't need to send the massive request again. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -----Original Message----- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Tuesday, February 10, 2009 5:11 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests Also becomes more of a problem when my page's JS would have to know for subsequent requests how to get the cached version, and not simply do a PRG again, because it would not know if a cached version existed. Even if I sent a probing GET request pre-all reformatting requests, the JS would not have the hash. And now I'd be doing 3 requests for every 1 I was doing beforehand. -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -----Original Message----- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Tuesday, February 10, 2009 2:53 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests Ok, then the /URL/1 part becomes the problem for me. I can make the GET redirect request I send back to have the same key pairs in it to retrieve the same content and cache it, but again, then the redirect GET is longer than 2k (or however long the POST content was, just in the GET format), and I run into the IE truncate problem. I'd have to construct a URL that's: 1. <= 2k and 2. Has enough uniqueness that no 2 gets for different content are the same. 3. Has some way of tieing that get url into the same POST content. Something like, POST the content, have the app server MD5 hash the content (which if it's large, like 1MB put a strain on the app-server), put the content and hash somewhere (app server, db, memcached), respond with the redirect GET url including the hash in it, then when the redirect request comes back to the app server, recognize a hash is in it, and have it pull the content for that hash, and then apache subsequently would cache based on that URL with the hash in it. MIGHT be work the extra request and hashing time/storage. -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -----Original Message----- From: Houser, Rick [mailto:houser.r...@aoins.com] Sent: Tuesday, February 10, 2009 2:24 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests Is this a little clearer? Notice how the Get request and post response are both tiny. This also opens up a whole slew of other possibilities now that you have a per-request URL to access. Current (as I understand it): -> POST (DOC file #1, 800KB) <- 200 OKAY (PDF file 600KB - non-cacheable, and substantial usability problems) Alternative (post, redirect, get): -> POST (DOC file #1, 800KB) <- REDIRECT FOR GET /URL/1 (< 1KB) (non-cacheable) -> GET /URL/1 (< 1KB) <- 200 OKAY (PDF file 600KB - easily cacheable, options for bookmarking, etc.) Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -----Original Message----- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Tuesday, February 10, 2009 3:46 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests I did mean requests, yes. We run a content reformatting service using Tomcat, so in reality the responses are large also, because nearly the same content (formatted differently) is sent back. Another problem I found with large GETs is that IE will truncation them if they are 2k or larger. Now, if that is pre- rendering engine or in the actual engine, I don't know? If it's pre then maybe the limit wouldn't be affected a redirect? That gets a little off-topic. Thanx, -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -----Original Message----- From: Houser, Rick [mailto:houser.r...@aoins.com] Sent: Tuesday, February 10, 2009 12:20 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests You mean post REQUESTS, not RESPONSES, correct? GET requests shouldn't be very large, but it's not all that uncommon to have GET responses larger than 1GB (local LANS, etc.). Accept all the incomming data on a post (which could be 1+MB file attachments, etc.), generate a unique URL, and redirect the user there to fetch the result. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -----Original Message----- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Tuesday, February 10, 2009 1:52 PM To: modules-...@httpd.apache.org Subject: RE: cache POST requests I read that for the 1.0 spec, but thought for the 1.1 it was possible with the proper expiration headers. Although I do understand the keying problem. My problem is that my POSTs vary wildly in size from 5k to over a meg, and avg. out to about 45k. Being that GETs in apache by default are limited to 8k, I'll get a 414 error, so I'm not sure where I can turn to cache this. I suppose I can up the LimitRequestLine parameter to the max I need, but I'm not sure how kosher that is. Thanx, -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -----Original Message----- From: Houser, Rick [mailto:houser.r...@aoins.com] Sent: Tuesday, February 10, 2009 11:37 AM To: modules-...@httpd.apache.org; us...@httpd.apache.org Subject: RE: cache POST requests You really shouldn't be trying to cache responses to post requests. Completely from memory, but the HTTP spec says not to cache post responses. The URI is the base key to any caching implementations (with the addition of a select few vary headers, etc.), and your post data really doesn't factor in. The normal pattern to use in most of these situations is http://en.wikipedia.org/wiki/Post/Redirect/Get. Think of a post as a submission from the client. Once you have that submission, just tell the client where to get the appropriate resource with a GET request and leave the heavy lifting/caching until that request comes in. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -----Original Message----- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Tuesday, February 10, 2009 1:25 PM To: us...@httpd.apache.org Cc: modules-...@httpd.apache.org Subject: 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 abia...@formatdynamics.com http://www.formatdynamics.com