On Tue, Jan 19, 2010 at 7:23 AM, Ciprian Dorin, Craciun
<[email protected]> wrote:
> 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
> ~~~~
Installed the latest version of polipo (1.0.4.1), and the problem
is still here... :) (Has anyone gotten to look upon my previous email?
(The one above.)) (I summarize: the folks at kernel.org solved the
problem, but now I think it's polipo's fault.)
(Is anyone able to reproduce this?) (For me it works (as in
reproducable) even with curl through polipo.)
Thanks,
Ciprian.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
