Re: NULL-Request (Sect. 4.1)

>  > It seemed to use like a less obtrusive solution to the problem of
>  > existing broken post scripts was to add a general no-op (also somewhat
>  > useful for performance measurements) rather than bandaid the post
>  > method.  I believe you need to look at this solution in that light.
>
> I like John Franks's implementation, where inter-request CRLF's are
> dropped on a persistent connection.  However, I think it will be tricky
> to craft words to say that.  And I agree with Phillip Hallam-Baker's
> concern that gobbling CRLFs silently violates the request-response
> paradigm.  I recognize the possible utility of a null request, but it
> would seem to merit a response, which leads to the question, "What kind
> of response, when you don't know the protocol version, etc.?"
>
> I'm inclined instead to add a note in 7.2.2 (Entity Body - Length) that
> some older client implementations included a superfluous CRLF following
> an entity body, and that robust servers should ignore those extra
> characters.  (Yes, I recall that that's what we started with before
> heading toward the null request "solution".)

I guess I'm less concerned about "violating the request/response model
of HTTP".  Then again, I've designed two previous streaming protocol based
systems :-).

The above looks like another possibility that is not a band-aid solution.
I'm happy either with a general null-request solution, or with recrafting
7.2.2.  I am unhappy with any solution that would either hack individual
methods, or be version dependent or depend too much on the details of
the transport connection state.

But note the last paragraph of 7.2.2:
  When a Content-Length is given in a message where an entity body is allowed,
  its field value MUST exactly match the number of OCTETs in the entity body.
  HTTP/1.1 user agents MUST notify the user when an invalid length is
  recieved and detected.

Exactly what would you say?  What exactly would 7.2.2 look like?
And preferably notify new clients if they
are buggy, so that buggy implementations don't continue to be generated (less
important, but sometimes key).
				- Jim

Received on Wednesday, 24 April 1996 12:34:00 UTC