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
Received on Thu Dec 01 2011 - 12:42:11 MST
This archive was generated by hypermail 2.2.0 : Fri Dec 02 2011 - 12:00:01 MST