Re: [squid-users] set-cookie header and rfc2109

2010-05-20 Thread Angelo Höngens
On 20-5-2010 12:05, Mark Nottingham wrote:
> Note that there really isn't any specification that describes how
> cookies actually work in the wild. Hopefully that will change soon,
> thanks to .

Thanks, good to know!



-- 


With kind regards,


Angelo Höngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
--
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

a.hong...@netmatch.nl
www.netmatch.nl
--




Re: [squid-users] set-cookie header and rfc2109

2010-05-20 Thread Mark Nottingham
Note that there really isn't any specification that describes how cookies 
actually work in the wild. Hopefully that will change soon, thanks to 
.

Cheers,


On 20/05/2010, at 4:50 PM, Angelo Höngens wrote:

> On 20-5-2010 8:22, Henrik Nordström wrote:
>> ons 2010-05-19 klockan 22:22 +0200 skrev Angelo Höngens:
>> 
>>> http://wiki.squid-cache.org/SquidFaq/InnerWorkings
>>> 
>>> "The proper way to deal with Set-Cookie reply headers, according to RFC
>>> 2109 is to cache the whole object, EXCEPT the Set-Cookie header lines."
>> 
>> Wrong reference.
>> 
>> This is from the original Netscape Cookie specification. At that time
>> Cache-Control did not exists.
> 
> So if I understand you correctly, squid follows the behaviour dictated
> in the Netscape Cookie Specification (undated), which says set-cookie
> headers should never be cached. However, that was superseded by rfc2109
> (1997), which says they should be cached unless told not to.
> 
> So by that reasoning, I would say Squid does not follow rfc. Not that I
> care that much, but perhaps it would warrant an update in the
> documentation or the faq page?
> 
> -- 
> 
> 
> With kind regards,
> 
> 
> Angelo Höngens
> systems administrator
> 
> MCSE on Windows 2003
> MCSE on Windows 2000
> MS Small Business Specialist
> --
> NetMatch
> tourism internet software solutions
> 
> Ringbaan Oost 2b
> 5013 CA Tilburg
> +31 (0)13 5811088
> +31 (0)13 5821239
> 
> a.hong...@netmatch.nl
> www.netmatch.nl
> --
> 
> 

--
Mark Nottingham   m...@yahoo-inc.com




Re: [squid-users] set-cookie header and rfc2109

2010-05-20 Thread Henrik Nordström
tor 2010-05-20 klockan 08:50 +0200 skrev Angelo Höngens:

> So if I understand you correctly, squid follows the behaviour dictated
> in the Netscape Cookie Specification (undated), which says set-cookie
> headers should never be cached. However, that was superseded by rfc2109
> (1997), which says they should be cached unless told not to.

Correct.

> So by that reasoning, I would say Squid does not follow rfc. Not that I
> care that much, but perhaps it would warrant an update in the
> documentation or the faq page?

Correct.

Regards
Henrik




Re: [squid-users] set-cookie header and rfc2109

2010-05-19 Thread Angelo Höngens
On 20-5-2010 8:22, Henrik Nordström wrote:
> ons 2010-05-19 klockan 22:22 +0200 skrev Angelo Höngens:
> 
>> http://wiki.squid-cache.org/SquidFaq/InnerWorkings
>>
>> "The proper way to deal with Set-Cookie reply headers, according to RFC
>> 2109 is to cache the whole object, EXCEPT the Set-Cookie header lines."
> 
> Wrong reference.
> 
> This is from the original Netscape Cookie specification. At that time
> Cache-Control did not exists.

So if I understand you correctly, squid follows the behaviour dictated
in the Netscape Cookie Specification (undated), which says set-cookie
headers should never be cached. However, that was superseded by rfc2109
(1997), which says they should be cached unless told not to.

So by that reasoning, I would say Squid does not follow rfc. Not that I
care that much, but perhaps it would warrant an update in the
documentation or the faq page?

-- 


With kind regards,


Angelo Höngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
--
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

a.hong...@netmatch.nl
www.netmatch.nl
--




Re: [squid-users] set-cookie header and rfc2109

2010-05-19 Thread Henrik Nordström
ons 2010-05-19 klockan 22:22 +0200 skrev Angelo Höngens:

> http://wiki.squid-cache.org/SquidFaq/InnerWorkings
> 
> "The proper way to deal with Set-Cookie reply headers, according to RFC
> 2109 is to cache the whole object, EXCEPT the Set-Cookie header lines."

Wrong reference.

This is from the original Netscape Cookie specification. At that time
Cache-Control did not exists.

Regards
Henrik



[squid-users] set-cookie header and rfc2109

2010-05-19 Thread Angelo Höngens
Hey guys,

I have question about rfc compliancy in regard to caching set-cookie
headers. According to the faq, squid does not return set-cookie headers
for hits, and I am very happy that it works this way.

It does not really make sense to me for an application to send a
cache-control:public header and then set a cookie, but that aside. I had
a discussion with one the our developers, I want to see where in the
rfc's this behaviour is dictated.

The Squid faq says:

http://wiki.squid-cache.org/SquidFaq/InnerWorkings

"The proper way to deal with Set-Cookie reply headers, according to RFC
2109 is to cache the whole object, EXCEPT the Set-Cookie header lines."


However, when I read rfc2109, I cannot find the directive that states
proxies must not cache these headers. On the contrary, the RFC talks
about "A Set-cookie header that is intended to be shared by multiple
users may be cached", and tells you that if you don't want to cache this
header, you should indicate so by setting the header "Cache-control:
no-cache="set-cookie":

http://www.ietf.org/rfc/rfc2109.txt

"4.2.3  Controlling Caching

   An origin server must be cognizant of the effect of possible caching
   of both the returned resource and the Set-Cookie header.  Caching
   "public" documents is desirable.  For example, if the origin server
   wants to use a public document such as a "front door" page as a
   sentinel to indicate the beginning of a session for which a Set-
   Cookie response header must be generated, the page should be stored
   in caches "pre-expired" so that the origin server will see further
   requests.  "Private documents", for example those that contain
   information strictly private to a session, should not be cached in
   shared caches.

   If the cookie is intended for use by a single user, the Set-cookie
   header should not be cached.  A Set-cookie header that is intended to
   be shared by multiple users may be cached.

   The origin server should send the following additional HTTP/1.1
   response headers, depending on circumstances:

   * To suppress caching of the Set-Cookie header: Cache-control: no-
 cache="set-cookie".
"
and a little down:

"4.5  Caching Proxy Role

   One reason for separating state information from both a URL and
   document content is to facilitate the scaling that caching permits.
   To support cookies, a caching proxy must obey these rules already in
   the HTTP specification:

   * Honor requests from the cache, if possible, based on cache validity
 rules.

   * Pass along a Cookie request header in any request that the proxy
 must make of another server.

   * Return the response to the client.  Include any Set-Cookie response
 header.

   * Cache the received response subject to the control of the usual
 headers, such as Expires, Cache-control: no-cache, and Cache-
 control: private,

   * Cache the Set-Cookie subject to the control of the usual header,
 Cache-control: no-cache="set-cookie".  (The Set-Cookie header
 should usually not be cached.)

   Proxies must not introduce Set-Cookie (Cookie) headers of their own
   in proxy responses (requests)."


Is this a 'bug' in the documentation/squid, is it a well-considered
deviation from rfc, or am I missing something?
-- 


With kind regards,


Angelo Höngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
--
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

a.hong...@netmatch.nl
www.netmatch.nl
--