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"
> <henrik_at_henriknordstrom.net>
> To: "Riccardo Castellani" <r.castellani_at_usl6.toscana.it>
> Cc: "'Amos Jeffries'" <squid3_at_treenet.co.nz>; <squid-users_at_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