On 2/12/2011 1:12 a.m., David Wojak wrote:
On 11/30/2011 01:48 PM, David Wojak wrote:
Client to Server (via proxy):
GET http://bla.bla.bla:8080/afdc3604/lib/commons-logging-1.1.1.jar
HTTP/1.1
Host: tlptest.m2n.at:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101
Firefox/8.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Proxy-Connection: keep-alive
Cache-Control: no-cache
Proxy to origin server:
GET /afdc3604/lib/commons-logging-1.1.1.jar HTTP/1.1
If-Modified-Since: Tue, 29 Nov 2011 12:21:04 GMT
Host: bla.bla.bla:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101
Firefox/8.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Via: 1.1 proxytest (squid/3.1.16)
Cache-Control: max-age=5999940
Connection: keep-alive
Origin Server to Proxy:
HTTP/1.1 304 Not Modified
Server: Jetty(6.1.16)
There is no Date header here. Which may be a problem as it makes the
304 invalid, but Squid assumes "now" and sends that to the client...
Well, thought of that too when I read the 304 specification... well,
I'll try that!
Proxy to client:
HTTP/1.0 200 OK
Date: Wed, 30 Nov 2011 08:27:16 GMT
Content-Type: application/java-archive
Content-Length: 66245
Last-Modified: Tue, 29 Nov 2011 12:21:04 GMT
Server: Jetty(6.1.16)
Warning: 110 squid/3.1.16 "Response is stale", 111 squid/3.1.16
"Revalidation failed"
X-Cache: HIT from proxytest
X-Cache-Lookup: HIT from proxytest:3128
Via: 1.0 proxytest (squid/3.1.16)
Connection: keep-alive
I've been checking up. It appears the Warning bug is not fixed yet.
It is wrong and can be ignored.
If you can, fix that Date up though.
Amos
Cool, thanks Amos! I'll try to fix the Date thingi on jetty-side.
I'll see if that makes a difference :)
Amos, can you give me an example of how a valid IMS with valid 304
response should look like? We changed the jetty header and tried
again, but still - revalidation failed.
Current Test:
Client to proxy:
GET http://bla.bla.bla:8080/3b8c257a/lib/commons-logging-1.1.1.jar
HTTP/1.1
Host: bla.bla.bla:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101
Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Proxy-Connection: keep-alive
Cache-Control: no-cache
Proxy to origin:
GET /3b8c257a/lib/commons-logging-1.1.1.jar HTTP/1.1
If-Modified-Since: Thu, 01 Dec 2011 10:25:55 GMT
Host: bla.bla.bla:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101
Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Via: 1.1 proxytest (squid/3.1.16)
Cache-Control: no-cache
Connection: keep-alive
Response:
HTTP/1.1 304 Not Modified
Date: Thu, 01 Dec 2011 11:05:59 GMT
Server: Jetty(6.1.16)
I've read something about "if you send cache-control with the get
request, you have to send back the same header with the 304 response"
- but couldn't confirm that reading the RFCs... Any idea? What does
squid need as response?
What that is about is that *if* the 304 contains one of the valid extra
headers like Cache-Control, the Squid response is supposed to be updated
to contain the new information. Those are optional extras which for now
you are not using.
Proxy to client:
HTTP/1.0 200 OK
Content-Type: application/java-archive
Content-Length: 66245
Last-Modified: Thu, 01 Dec 2011 10:25:55 GMT
Date: Thu, 01 Dec 2011 11:06:04 GMT
Server: Jetty(6.1.16)
Warning: 110 squid/3.1.16 "Response is stale", 111 squid/3.1.16
"Revalidation failed"
X-Cache: HIT from proxytest
X-Cache-Lookup: HIT from proxytest:3128
Via: 1.0 proxytest (squid/3.1.16)
Connection: keep-alive
and again in the log:
1322737561.457 9 192.168.100.215 TCP_REFRESH_UNMODIFIED/200 66658
GET http://bla.bla.bla:8080/3b8c257a/lib/commons-logging-1.1.1.jar -
DIRECT/192.168.100.170 application/java-archive
That is a success. The client is requesting a whole new copy, so Squid
is required to send a 200 with new copy. But is optimizing the backend
check to use 304.
The warning is a minor bug, Squid is adding it based on the
before-validation information about the request.
I was expecting Squid to update the Last-Modified date to the client to
say "Thu, 01 Dec 2011 11:05:59 GMT" from the 304, but will have to
double-check the code and RFCs about that.
Amos
