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
