Re: hallam@w3.org: Netscape Bug or KeepAlive Feature ?

The extra CRLF is sent to fix bugs in cgi programs.  The
problem stems from the use of PERL to parse cgi input.
If you use a getline function it will only return data
at every CRLF boundary.  If browsers don't send a final
CRLF at the end of the post data, many cgi programs will
never get the data since the post data does not normally
contain a CRLF at the end.  

Perhaps we can do something to fix this for the 1.1 draft
so that we can stop sending the extra CRLF.

:lou

Andy Norman wrote:
> 
> [This was meant for the least -- ange]
> 
> ------- Forwarded Message
> 
> Date:    Sat, 02 Mar 1996 18:59:36 -0500
> From:    hallam@w3.org
> To:      http-wg-request@cuckoo.hpl.hp.com
> Subject: Netscape Bug or KeepAlive Feature ?
> 
> I have been looking into the action of posting forms.
> 
> - --------------
> POST / HTTP/1.0
> Referer: http://************
> Connection: Keep-Alive
> User-Agent: Mozilla/2.0b6a (X11; I; OSF1 V3.2 alpha)
> Host: zorch.w3.org:5000
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
> Content-type: application/x-www-form-urlencoded
> Content-length: 36
> 
> action=Submit&text=This+is+some+data
> 
> - --------------
> 
> Now by my reconing the final CRLF is bogus. I would expect the next
> transaction to start. The HTTP/1.1 spec does not require a trailing
> CRLF and the entity is precisely 36 bytes:-
> 
> action=Submit&text=This+is+some+data
> 123456789012345678901234567890123456
> 
> This is worrying me, is there a plan to permit footers on keepalive
> transactions and the CRLF is simply an artifact of that. Or is there
> a "feature" here that people have been writing code ?
> 
> I got the same result from Mosaic:
> 
> - --------------
> POST / HTTP/1.0
> Accept: */*, q=0.300
> Accept: text/plain
> Accept: text/html
> User-Agent: Spyglass_Mosaic/2.10 OSF1V2.0 Spyglass/9
> Accept-Language: en
> Connection: Keep-Alive
> Referer: http://www.w3.org/pub/WWW/WIT/Specification/entry.html
> Content-type: application/x-www-form-urlencoded
> Content-length: 36
> Extension: Security/Digest
> Extension: Payment/FirstVirtual
> 
> text=This+is+some+data&action=Submit
> 
> - --------------
> 
> Is this simply me misreading the 1.1 spec or have we got an issue
> here? It would be "upsetting" to discover that forms handling programs
> were dependent on a bogus trailing CRLF to teminate a www-form-urlencoded
> data item.
> 
>                 Phill
> 
> [Isn't it nice to be able to get some coding done with everyone at the
> IETF :-) ]
> 
> ------- End of Forwarded Message

-- 
Lou Montulli                 http://www.netscape.com/people/montulli/
       Netscape Communications Corp.

Received on Monday, 4 March 1996 12:55:22 UTC