RE: Implementing HTTP PUT

> -----Original Message-----
> From: www-talk-request@w3.org [mailto:www-talk-request@w3.org]On Behalf
> Of Aaron Swartz
> Sent: Wednesday, March 28, 2001 1:59 PM
> To: Fish; www-talk@w3.org
> Subject: Re: Implementing HTTP PUT
>
>
> Thanks so much for your thoughtful and comprehensive letter on HTTP PUT.

You're very welcome, Aaron. I'm glad I could help some.

> I am still working through all of it, but first I thought it would be smart to
> clear up my incompatibility with Amaya.
>
> Fish <fish@infidels.org> wrote:
>
> > Was there an "Expect: 100-continue" header in the request? If so, then you
> > should have responded to the PUT request with two separate responses: the
> > first being a "100 Continue" response and the second a "200 OK" final status
> > response.
>
> Aha! This seems to be the problem. Using EricP's excellent patchPannel
> (thanks to Gerald and dajobe), I find that Amaya is sending the following
> request:
>
> PUT /testing HTTP/1.0
> Accept: text/html
> Accept-Encoding: *,deflate
> TE: trailers,deflate
> Expect: 100-continue

Ha! Told ya.  ;-)

> Host: logicerror.com:8000
> If-Match: "2FCD2DA8CE70C6513671F8B181CCAB94F52F00B7"
> User-Agent: amaya/V4.0 libwww/5.3.1
> Cache-Control: no-cache
> Connection: TE,Keep-Alive
> Date: Wed, 28 Mar 2001 07:07:20 GMT
> Content-Length: 1266
> Content-Type: text/html
> Last-Modified: Wed, 28 Mar 2001 07:07:20 GMT
>
> This is interesting because it's an HTTP/1.0 request, but uses Expect:
> 100-continue. As the RFC you referenced states:
>
>     An origin server [...] MUST NOT send a 100 (Continue) response if such a
>     request comes from an HTTP/1.0 (or earlier) client.

Huh?!

<grabs RFC 2616 and re-reads section 8.2.3...>

Aaron!  Shame on you. :)

> So it seems odd that Amaya is expecting a response that according to the RFC
> I am not allowed to send it.

You're reading it wrong. Put the words you removed from the paragraph you quoted
above (represented by the "[...]" ellipsis you inserted) and read it again.

Here, I'll do it for you:

      - An origin server SHOULD NOT send a 100 (Continue) response if
        the request message does not include an Expect request-header
        field with the "100-continue" expectation, and MUST NOT send a
        100 (Continue) response if such a request comes from an HTTP/1.0
        (or earlier) client. [...]

The key words in the above paragraph are: "if the request message does NOT
include an Expect request-header field with the "100-continue" expectation."
(emphasis mine)

In other words:

   IF:
   (a) the request does NOT include an "Expect: 100-Continue" header,
   AND
   (b) the request is from an HTTP/1.0 or earlier client,
   THEN:
   an origin server MUST NOT send a 100 Continue response.

But it says *nothing* about how to react to receiving a request from an HTTP/1.0
or earlier client that DOES include an "Expect: 100-Continue" header, now does
it? No. It doesn't.

IMHO if a request is received that includes an "Expect: 100-Continue" header,
then it's obvious the client is actually expecting to receive a 100 Continue
response, *regardless* of whether it came from an HTTP/1.1 or HTTP/1.0 client.

Let me say that again: If the request includes an "Expect: 100-Continue" header
then you SHOULD send a 100 Continue response before sending your final status
response in most all cases. The only exceptions are:

1. if you wish to reject the request outright based on the received request
headers (in which case you can send a final status response right away without
an intervening 100 Continue),

OR

2. in the case where you receive the entity body portion of the request along
with the request headers (in which case sending a 100 Continue response would be
superfluous since the client is already "continuing". :) But even in this case,
there's no harm in sending one anyway. The protocol simply states that you MAY
refrain from sending one, but it *doesn't* say you shouldn't or mustn't.)

The point is, the paragraph you're quoting from is describing how origin servers
should react to requests that do NOT have an "Expect: 100-Continue" header, but
the request YOU received DID have one. Thus, you SHOULD have sent a 100 Continue
response (unless, as I said, one of the above two exceptions apply).

The last paragraph of section 8.2.3 (immediately preceding section 8.2.4) that
discusses the requirements for HTTP/1.1 proxies states:

      - A proxy MUST NOT forward a 100 (Continue) response if the
        request message was received from an HTTP/1.0 (or earlier)
        client and did not include an Expect request-header field with
        the "100-continue" expectation. [...]

This implies that there are indeed some HTTP/1.0 clients in existence that send
requests with "Expect: 100-Continue" headers. And in your case we know this to
be absolutely true: you DID afterall receive a request from an HTTP/1.0 client
that DID include an "Expect: 100-Continue" header, did you not? :)

Never mind that the above paragraph pertains to proxies and not origin servers.
That's not the point. The point is what it implies, and what it implies is what
I just stated above: that HTTP/1.0 clients MAY send requests that DO include
"Expect: 100-Continue" headers, in which case you SHOULD send a 100 Continue
response (unless one of the previously mentioned exceptions apply).

Is that clear as mud now? :)

> When I do not send the 100 continue response
> Amaya sends the response body, and then crashes. This seems to be in line
> with this part of the RFC:
>
>     the client SHOULD NOT wait for an indefinite period before sending the
>     request body.
>
> (except for the crash). I reported this to the Amaya team:
>
> http://lists.w3.org/Archives/Public/www-amaya/2001JanMar/0264.html
>
> (Also interesting is that I'd never seen RFC2616 -- only 2068, which I had
> assumed was the latest.)

You assumed wrong. :)

But don't feel bad. I did the same thing a while back. :)

RFC 2068 was, for a long time, the only document that described HTTP/1.1. I
based development of my proxy on RFC 2068 myself until RFC 2616 came out. Once
it did, I made whatever changes I needed to make to make my proxy fully HTTP/1.1
compliant (based on the differences between the 2068 I was using and the 2616
that became the official standard). (I don't recall anymore how drastically
different 2616 was from 2068, but not much as I recall. Just a few things here
and there.)

> So what is the correct thing to do in this instance? Hmm, let's ask Jigsaw:
>
> PUT /Overview.html HTTP/1.1

Please note that this particular request is coming from an HTTP/1.1 client and
not from an HTTP/1.0 client like in your first example. (Just thought I'd point
that out in case you were trying to pull a fast one on me. :)

> Accept: text/html
> Accept-Encoding: *,deflate
> TE: trailers,deflate
> Expect: 100-continue
> Host: dev.logicerror.com:8001
> If-Match: "mvanct:sm348cgo"
> User-Agent: amaya/V4.0 libwww/5.3.1
> Cache-Control: no-cache
> Connection: TE
> Date: Wed, 28 Mar 2001 07:38:26 GMT
> Content-Length: 3270
> Content-Type: text/html
> Last-Modified: Wed, 28 Mar 2001 07:38:26 GMT
>
> ----
>
> HTTP/1.1 100 Continue
> Date: Wed, 28 Mar 2001 19:29:25 GMT
> Server: Jigsaw/2.2.0

Right. :)

> ----
>
> (content of page)
>
> ----
>
> HTTP/1.1 204 No Content
> Date: Wed, 28 Mar 2001 19:29:27 GMT
> Content-Length: 3270
> Content-Type: text/html
> Etag: "mvanct:sm3bhheo"
> Last-Modified: Wed, 28 Mar 2001 19:29:27 GMT
> Server: Jigsaw/2.2.0

Hmmm. That's odd. A "204" response with a non-zero content length header. Looks
like a bug to me. The 204 response MUST NOT include a message-body, YET it
(Jigsaw) is saying (via the "Content-Length: 3270" and "Content-Type: text/html"
response headers) that it IS indeed sending one (a response that includes an
entity body, that is).

Better report that one. That's definitely a bug IMO.

> ----
>
> Hmm. So I guess I need to return two responses.

It all depends. :)

If the request you receive includes an "Expect: 100-Continue" header (and
neither of the two previously mentioned exceptions applies), then yes, you
SHOULD send two responses: a "100 Continue" followed by your final status.

If the request you receive does NOT include an "Expect: 100-Continue" header,
however, then MAYBE you need to return two responses. It all depends on whether
the request came from an HTTP/1.1 client or not. If the request was from an
HTTP/1.0 (or earlier) client, then you MUST NOT send a 100 Continue response,
but if the request came from an HTTP/1.1 client, then you simply SHOULD NOT send
one (but MAY if you so desire in order to be compatible with RFC 2068).

> This will be difficult,
> because it will need to be added to the server itself, not my code.

<scratches head and looks confused>

Um, I thought you *were* the server?

<refers back to previous email>

"[...] In my first experimentation with it, when I returned a 200 response
with a text/plain body of "OK", Amaya claimed there was an error of "OK".
So I believe I'm missing something. [...]"

This would imply that you're the server, sending responses to PUT requests, no?

> Plus
> it's a HTTP/1.0 server, so I'm not sure if it would be right to report it as
> a bug.

Agreed. RFC 1945 (HTTP/1.0) only mentions PUT very briefly in appendix D.1.1 and
provides no details as to how it should be used. I seriously doubt there are
very many HTTP/1.0 servers out there that support PUT requests.

> > See RFC 2616 section 8.2.3 "Use of the 100 (Continue) Status". (But you knew
> > that, right? How familiar are you with HTTP/1.1 anyway? Please
> understand I'm
> > not bashing you; I'm just curious, that's all. It helps to know the
> background
> > and experience of the person asking the question.)
>
> I'm just an interested Web developer, but with little knowledge of HTTP.
> Hopefully, if I can get this to work, I'll write it up for others. I'd love
> to see PUT more widely available.

Have you tried one of those free web space services out there (like "freedrive"
or some such) that provide a web interface for users to upload files? Perhaps
they support PUT? <shrug> Just a thought.

> --
> [ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

(p.s. There's no need for you to send a CC copy of your reply directly to me
since I'm subscribed to the www-talk list. When you do, I end up receiving two
copies of the same reply: one from you and one from the list. Just send your
reply directly to the list and I'll receive it just fine. Honest. :)

--
"Fish" (David B. Trout)
   fish@infidels.org

Received on Thursday, 29 March 2001 02:52:00 UTC