On Tue, Jan 19, 2010 at 6:56 AM, J.H. <[email protected]> wrote:
> On 01/18/2010 05:22 PM, Juliusz Chroboczek wrote:
>>>>> < Expires: never
>>
>>> <<Expires: never>> as in "this page shall never expire!".
>>
>> Em, no. "Expires: never" is treated by Polipo as "Expires: 0", meaning
>> that the page is not cached. This behaviour is actually mandated by
>> RFC 2616 14.21:
>>
>> HTTP/1.1 clients and caches MUST treat other invalid date formats,
>> especially including the value "0", as in the past (i.e., "already
>> expired").
>>
>> So the headers sent by the server are correct, if somewhat confusing.
>> Ideally, the server should do the following:
>>
>> To mark a response as "already expired," an origin server sends an
>> Expires date that is equal to the Date header value.
>>
>> The issue is with something else, and it would be good to work it out.
>> For what it's worth, I cannot reproduce it on my side.
>
> Well as a note I've already changed the code that runs git.kernel.org
> (did it this morning in fact), the cache expires "now" which is the
> timestamp of whenever the process generated the header, as well as
> adding additional caching hints. I can throw back up a testing copy of
> the code somewhere if it's helpful to you guys in tracking down what the
> problem was.
>
> - John 'Warthog9' Hawley
Indeed the latest code at kernel.org works correctly and sets the
Expire header to now.
But somehow the problem still remains... :(
But this time I would say that it's strictly Polipo's fault.
(So no need to put the old code somewhere as I can still reproduce
the bug. :) )
Now clear things out, I've tested the issue (with and without
Polipo) in Firefox and Chromium, and the result was: with Polipo both
enter into an infinite loop, without both reload the generated page.
(The only big difference is that Firefox goes 100% CPU and blocks,
while Chromium still remains usable. I'll also file a bug for Firefox
as this is a potential issue.)
Also I'm 99% sure that I don't have a transparent proxy upstream
(for example the same issue happens also when I exit from my
universities network, and there I'm 100% that our administrators
didn't do such a thing, and 99.9% for the upstream network.)
(My version of Polipo is not the latest, it is 1.0.4. But maybe
I'll try today to update it.)
At the end is the answer of Polipo (with curl setup to pass
through Polipo). Interesting is the following headers (received from
Polipo) :
< Age: 276
< Warning: 110 [email protected].:23048 Object is stale
So once again,
Thank you for all your effort,
Ciprian.
~~~~
> GET
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commitdiff;h=fc95845f174a07d4200a30681067d22c9e34723c
> HTTP/1.1
> User-Agent: curl/7.19.7 (i686-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8l
> zlib/1.2.3.4
> Host: git.kernel.org
> Accept: */*
> Proxy-Connection: Keep-Alive
~~~~
< HTTP/1.1 200 OK
< Content-Length: 533
< Date: Tue, 19 Jan 2010 05:07:28 GMT
< Expires: Tue, 19 Jan 2010 05:07:28 GMT
< Cache-Control: no-cache, private, no-store, must-revalidate
< Server: Apache/2.2.14 (Fedora)
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Age: 276
< Connection: keep-alive
< Warning: 110 [email protected].:23048 Object is stale
~~~~
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
