RE: NULL-Request (Sect. 4.1)

This is not as good as saying it is at the beginning, from the
standpoint of straightforward parsing. It is harder to look for optional
stuff at the end, when no more stuff may be forthcoming -- I don't know
how long to wait to see if it arrives. It is easy to discard optional
stuff at the beginning -- I've already decided to wait for a request,
and I just throw out initial CRLFs.

Paul "speaks from having his web server hung by similar things"

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Wednesday, April 24, 1996 1:30 PM
>To: 	jg@w3.org
>Cc: 	dmk@allegra.att.com; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Re: NULL-Request (Sect. 4.1)
>
>jg@w3.org:
>>
>>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.
>
>How about this:
>
>             Full-Request   = Request-Line              ; Section 5.1
>                              *( General-Header         ; Section 4.3
>                               | Request-Header         ; Section 5.2
>                               | Entity-Header )        ; Section 7.1
>                              CRLF
>                              [ Entity-Body ]           ; Section 7.2
>                              [ CRLF ]
>                              ^^^^^^^^
>
>Together with a text
>
> Clients SHOULD NOT include the optional CRLF at the end of a request,
> but servers MUST be tolerant of clients which do include this CRLF.
>
>   Note: Many existing HTTP/1.0 clients add a CRLF at the end of a POST
>   request.
>
>Koen.
>
>

Received on Wednesday, 24 April 1996 13:48:56 UTC