[tahoe-dev] [tahoe-lafs] #462: PUT should elicit 100 Continue

tahoe-lafs trac at tahoe-lafs.org
Thu Jan 13 05:43:49 UTC 2011


#462: PUT should elicit 100 Continue
-----------------------------------+----------------------------------------
     Reporter:  adi                |       Owner:                                      
         Type:  defect             |      Status:  new                                 
     Priority:  major              |   Milestone:  1.9.0                               
    Component:  code-frontend-web  |     Version:  1.1.0                               
   Resolution:                     |    Keywords:  curl hang reliability http standards
Launchpad Bug:                     |  
-----------------------------------+----------------------------------------
Changes (by davidsarah):

  * keywords:  curl hang reliability => curl hang reliability http
               standards
  * milestone:  undecided => 1.9.0


Comment:

 We are clearly non-compliant to a MUST requirement in
 [http://tools.ietf.org/html/rfc2616#section-8.2.3 RFC 2616 section 8.2.3]:
 {{{
 Upon receiving a request which includes an Expect request-header
 field with the "100-continue" expectation, an origin server MUST
 either respond with 100 (Continue) status and continue to read
 from the input stream, or respond with a final status code. The
 origin server MUST NOT wait for the request body before sending
 the 100 (Continue) response.
 }}}

 Mind you, curl is also non-compliant to a SHOULD:
 {{{
 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.
 }}}

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/462#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-dev mailing list