ok i've found some info about it but it is a bit confusing 1. content-length header is a end to end header so proxies has to forward it to the browser
But, according to: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. And that is what i meant on my first post, it is not clear :-) I interpret that as if original webserver sends a content-length header with a 204 reply, this header has to be forwarded to the end node hence the browser. But if the original webserver sends a 204 with no CL header, it is also a valid reply and it should work. I could not see a lan trace on the cisco device but i've got one when it was removed and on this one i saw the CL header and when going directly to the same website, the original website sends the CL header so at this point i will blame the cisco device to remove the CL header. Thanks Gonzalo >>> Gonzalo Morera 18/11/2010 12:44 PM >>> Hi Amos Thanks a lot for your answer The request method is just a GET and with streetview option i was referring to the yellow man on goggle maps :-) I could not get a lan trace between squid and the cisco device so i do not know what the cisco device is sending but if it is remove it, squid sends the 204 with the content-length and everything works. I see the same behavior with different proxies like bordermanager or superlumin. All send the content-length header. Could be possible if you point me to the docs about this subject, please? Thanks again Gonzalo >>> Amos Jeffries <[email protected]> 18/11/2010 12:33 PM >>> On 18/11/10 23:23, Gonzalo Morera wrote: > Hi > > Please, disregard my previous post. In front of the squid server there is a > Cisco appliance and it is the one causing the issue, so sending the 204 > without a content-length header. Once the Cisco is removed, traces showed > squid sending the 204 with the content-length header hence working as it > should > > Thanks > > Gonzalo :) Well, to answer your technical Q about the RFCs. With a 204 reply the content-length header is usually optional. Squid sends a few headers like connection: and content-length: on a lets-be-safe basis. The RFCs specify that the content-length:0 MUST exist for certain request methods (OPTIONS being one, was that what you meant by "the streetview options"?). And MUST NOT exist for certain types of encoding replies. That is all. content-length is OPTIONAL in all other bodiless cases. Disclaimer: I'm not an authority on the RFCs. Just spent lots of time reading figuring out the text. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.3
