tahoe-lafs/trac-2024-07-25

PUT should elicit 100 Continue #462

New issue

Open

opened 2008-06-13 07:01:06 +00:00 by adi · 1 comment

adi commented

2008-06-13 07:01:06 +00:00

Owner

curl -T foo.txt http://tahoebs1.allmydata.com:8123/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/foo.txt should work. Currently, curl sends the PUT and the headers and then blocks waiting for the server to tell it to go ahead.

curl -T foo.txt <http://tahoebs1.allmydata.com:8123/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/foo.txt> should work. Currently, curl sends the PUT and the headers and then blocks waiting for the server to tell it to go ahead.

tahoe-lafs added the

labels 2008-06-13 07:01:06 +00:00

tahoe-lafs added this to the undecided milestone 2008-06-13 07:01:06 +00:00

tahoe-lafs added

code-frontend-web

and removed

unknown

labels 2008-08-19 18:01:48 +00:00

davidsarah commented

2011-01-13 05:43:49 +00:00

Author

Owner

We are clearly non-compliant to a MUST requirement in 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.

We are clearly non-compliant to a MUST requirement in [RFC 2616 section 8.2.3](http://tools.ietf.org/html/rfc2616#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. ```

tahoe-lafs modified the milestone from undecided to 1.9.0

2011-01-13 05:43:49 +00:00

tahoe-lafs modified the milestone from 1.9.0 to soon

2011-07-12 22:46:48 +00:00