Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
2) Squid recognizes a broken request (with a header that it can't handle)... 1- Do you reference broken request because you want to say that there is written both expect:100 continue header and http/1.0 protocol ? If it was so, Squid should break connection if I don't use ignore_expect_100 on option 2) Squid recognizes a broken request (with a header that it can't handle) and terminates the request with a visible error explaining exactly what is going on if Squid ignored broken request (with a header that it can't handle + http/1.0 specified ) HTTP Server always would give 417 error ? So Squid only would predict behavoiur of server... What do you think ? - Original Message - From: Chris Robertson crobert...@gci.net To: squid-users@squid-cache.org Sent: Friday, February 19, 2010 9:04 PM Subject: Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed Riccardo Castellani wrote: I ask if Squid previous versions ignored Expect header forwarding request to server. But now why Squid code (2.7 version) detects this header and it handles it as error ? Why has this Squid behaviour been modified ? Given the following scenario... Some random software, upon receiving notification that there is a HTTP/1.0 link in the chain decides to ignore that fact and use a HTTP/1.1 method (against protocol) ...which outcome would you prefer: 1) Squid accepts the traffic, unrecognized request header (Expect: 100-Continue) and all, and silently fails when the response comes in, or returns a partial response as if it was complete. or 2) Squid recognizes a broken request (with a header that it can't handle) and terminates the request with a visible error explaining exactly what is going on. Personally, I like to know why things break when they inevitably do. Chris
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
In the case of 100-continue a 417 response means that 100 Continue interim response can not be expected to be seen and the client needs to resend the request only using the delay heuristics when sending request entities (PUT/POST etc..), and then obviously without the Expect: 100-continue. What means using the delay heuristics ? Why it should be necessary to send using delays ? Heuristics ?! Some client can crate request with both this header and http1.0 protocol ?! - Original Message - From: Henrik Nordström hen...@henriknordstrom.net To: Riccardo Castellani r.castell...@usl6.toscana.it Cc: 'Amos Jeffries' squ...@treenet.co.nz; squid-users@squid-cache.org Sent: Friday, February 19, 2010 9:15 PM Subject: Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed fre 2010-02-19 klockan 14:57 +0100 skrev Riccardo Castellani: I ask if Squid previous versions ignored Expect header forwarding request to server. But now why Squid code (2.7 version) detects this header and it handles it as error ? Why has this Squid behaviour been modified ? Because more and more of HTTP/1.1 is getting implemented. Part of getting HTTP/1.1 implemented is proper processing of Expect, which includes responding with 417 if the Expect condition can not be fulfilled. Any software sending Expect also need to be prepared to receive a 417 response back as response to the expectation and deal with it accordingly. In the case of 100-continue a 417 response means that 100 Continue interim response can not be expected to be seen and the client needs to resend the request only using the delay heuristics when sending request entities (PUT/POST etc..), and then obviously without the Expect: 100-continue. Due to the amount of broken software out there not prepared to deal with 417 responses Squid-2.7 has a directive to disable 100-continue expectation processing. ignore_expect_100 Regards Henrik
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
Riccardo Castellani wrote: In the case of 100-continue a 417 response means that 100 Continue interim response can not be expected to be seen and the client needs to resend the request only using the delay heuristics when sending request entities (PUT/POST etc..), and then obviously without the Expect: 100-continue. What means using the delay heuristics ? Why it should be necessary to send using delays ? Heuristics ?! Some client can crate request with both this header and http1.0 protocol ?! RFC 2616: 8.2.3 Use of the 100 (Continue) Status The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. ... - If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (section 14.20) with the 100-continue expectation. ... Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send Expect: 100- continue without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body. Sending Expect: 100-continue is an explicit HTTP/1.1 statement that the request has been broken into two parts with an unknown-length delay in the middle while it waits for one of a 100-continue or 417-failed message to be sent back. No Squid will relay a 100 message back. Squid-2.7 when advertising itself as HTTP/1.1 will send back the 417. Squid-3.x advertise as HTTP/1.0 so that other HTTP/1.1 compliant software can generate the 417 reply on its behalf. Expect: is a feature which MUST NOT be used/sent through HTTP/1.0 software such as Squid. Amos - Original Message - From: Henrik Nordström hen...@henriknordstrom.net To: Riccardo Castellani r.castell...@usl6.toscana.it Cc: 'Amos Jeffries' squ...@treenet.co.nz; squid-users@squid-cache.org Sent: Friday, February 19, 2010 9:15 PM Subject: Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed fre 2010-02-19 klockan 14:57 +0100 skrev Riccardo Castellani: I ask if Squid previous versions ignored Expect header forwarding request to server. But now why Squid code (2.7 version) detects this header and it handles it as error ? Why has this Squid behaviour been modified ? Because more and more of HTTP/1.1 is getting implemented. Part of getting HTTP/1.1 implemented is proper processing of Expect, which includes responding with 417 if the Expect condition can not be fulfilled. Any software sending Expect also need to be prepared to receive a 417 response back as response to the expectation and deal with it accordingly. In the case of 100-continue a 417 response means that 100 Continue interim response can not be expected to be seen and the client needs to resend the request only using the delay heuristics when sending request entities (PUT/POST etc..), and then obviously without the Expect: 100-continue. Due to the amount of broken software out there not prepared to deal with 417 responses Squid-2.7 has a directive to disable 100-continue expectation processing. ignore_expect_100 Regards Henrik -- Please be using Current Stable Squid 2.7.STABLE8 or 3.0.STABLE24 Current Beta Squid 3.1.0.16
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
lör 2010-02-20 klockan 11:11 +0100 skrev Riccardo Castellani: What means using the delay heuristics ? Why it should be necessary to send using delays ? Heuristics ?! Because of the reasons why 100 Continue exists.. without 100 Continue the clients second option is to send headers, wait a bit for the headers to most likely arrive and get processed by the server (including forwarded by proxies etc) and then start sending the body when it's known within reasonable doubt that the request is acceptable to the server. the third option is to just chew along, sending all the data immediately and hope for the best. But for any larger request this has a high risk of failure with Connection reset if anything (proxy, server or surrogate server) refuses or fails the request, or in best case wastes network resources by sending data which will be discarded. All above in case of an error, naturally not if the request is successfully processed. Some client can crate request with both this header and http1.0 protocol ?! Every HTTP/1.1 client can, simply by being proxied by an HTTP/1.0 proxy. HTTP protocol minor version is a hop-by-hop property (not end-to-end) and is for most processing of the HTTP protocol irrelevant. The only two places where you need to take note of the received HTTP protocol version is a) In servers, when considering to respond with chunked encoding. b) In clients, when considering to sent request entities using chunked encoding. chunked encoding is also a hop-by-hop property btw.. Everywhere else each recipient should process the message according to it's own protocol implementation. The errors 417 and 411 is both very similar in this regard, negating the use of certain HTTP/1.1 features. 417 tells the client that it can not expect an 100 Continue message and that it need to adjust it's request sending policy accordingly. 411 says that chunked encoding can not be used and requests need to be sent with Content-length if they have a request entity body. Regards Henrik
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
lör 2010-02-20 klockan 11:08 +0100 skrev Riccardo Castellani: 2) Squid recognizes a broken request (with a header that it can't handle)... 1- Do you reference broken request because you want to say that there is written both expect:100 continue header and http/1.0 protocol ? If it was so, Squid should break connection if I don't use ignore_expect_100 on option Broken is bad wording. RFC2616 has very strict requirements on how proxies need to act on Expect: 100-continue, requiring proxies to respond with 417 in many cases. if Squid ignored broken request (with a header that it can't handle + http/1.0 specified ) HTTP Server always would give 417 error ? No, but the client would be left in the uncertain land of never actually getting an 100 Continue response. Regards Henrik
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
lör 2010-02-20 klockan 23:47 +1300 skrev Amos Jeffries: Expect: is a feature which MUST NOT be used/sent through HTTP/1.0 software such as Squid. There is no such requirement actually. But the 2616 specifications for 100 Continue is also slightly broken/inconsistent in that area... Regards Henrik
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
Riccardo Castellani wrote: I ask if Squid previous versions ignored Expect header forwarding request to server. But now why Squid code (2.7 version) detects this header and it handles it as error ? Why has this Squid behaviour been modified ? Given the following scenario... Some random software, upon receiving notification that there is a HTTP/1.0 link in the chain decides to ignore that fact and use a HTTP/1.1 method (against protocol) ...which outcome would you prefer: 1) Squid accepts the traffic, unrecognized request header (Expect: 100-Continue) and all, and silently fails when the response comes in, or returns a partial response as if it was complete. or 2) Squid recognizes a broken request (with a header that it can't handle) and terminates the request with a visible error explaining exactly what is going on. Personally, I like to know why things break when they inevitably do. Chris
Re: [squid-users] R: [squid-users] HTTP/1.0 417 Expectation failed
fre 2010-02-19 klockan 14:57 +0100 skrev Riccardo Castellani: I ask if Squid previous versions ignored Expect header forwarding request to server. But now why Squid code (2.7 version) detects this header and it handles it as error ? Why has this Squid behaviour been modified ? Because more and more of HTTP/1.1 is getting implemented. Part of getting HTTP/1.1 implemented is proper processing of Expect, which includes responding with 417 if the Expect condition can not be fulfilled. Any software sending Expect also need to be prepared to receive a 417 response back as response to the expectation and deal with it accordingly. In the case of 100-continue a 417 response means that 100 Continue interim response can not be expected to be seen and the client needs to resend the request only using the delay heuristics when sending request entities (PUT/POST etc..), and then obviously without the Expect: 100-continue. Due to the amount of broken software out there not prepared to deal with 417 responses Squid-2.7 has a directive to disable 100-continue expectation processing. ignore_expect_100 Regards Henrik
