RE: [Full-Disclosure] Strange netcat behavior

["thalm" <thalm@netcabo.pt>]

Ok, the difference between the tools is one thing. I only saw it through one 
perspective and I was wrong.
 
Now concerning the difference of behaviour of WebServers in terms of HTTP RFC 
and the need to have CRLF separating the HTTP "lines" (sorry for the term 
"lines" but I am sure you all understand it).
 
a) Why do Web Servers behave this way?
 
b) Which Web Browsers work by sending only LF?
I think a version of Internet Explorer 6 in Win98 does work this way (only 
LF)...but all others work the correct way, i.e, they send CRLF
 
Tiago Halm
http://www.kodeit.org

        -----Original Message----- 
        From: full-disclosure-admin@lists.netsys.com on behalf of Giovanni 
Giacobbi 
        Sent: Fri 10/17/2003 3:43 PM 
        To: full-disclosure@lists.netsys.com 
        Cc: 
        Subject: Re: [Full-Disclosure] Strange netcat behavior
        
        

        On Fri, Oct 17, 2003 at 01:56:02PM +0100, thalm wrote:
        > Since netcat is a widely used network tool, this may have been 
discussed already, but since I wasn't able to found such discussion, here goes:
        > 
        > When using netcat (Windows and Linux versions) to connect to a web 
server, and everytime ENTER is pressed in the command line, netcat only sends 
LF (0x0A) instead of CRLF (0x0D 0x0A).
        > ex: GET / HTTP/1.0[LF][LF]
        > 
        > when using telnet, the behavior is different:
        > ex: GET / HTTP/1.0[CRLF][CRLF]
        > 
        > Although webservers (IIS and probably Apache) don't mind such 
behavior and accept it (LF) as if it was CRLF, RFC 2616 clearly states that the 
HTTP Request/Response Line and HTTP Headers *MUST* be separated by a CRLF and 
not only by a LF.
        > 
        > Why is there such a difference between netcat and telnet behavior?
        > 
        
        Because they are different programs, with different purposes.
        Netcat is a stream handler, just like "cat". What it actually does is 
to take the source input stream
        and forward it to the output stream (a socket, in this case). 
Everything else is outside its scope.
        
        In your example, the difference is made by your TTY. Your TTY is 
actually feeding Netcat with a single
        linefeed, while telnet parses the input and converts manually those 
linefeeds in cr/lf combinations.
        Also, Netcat has no clue about what a "line" is, it doesn't make any 
difference between sent bytes,
        as it is binary-safe.
        
        I yet have to find a way to tell linux terminal to convert carriage 
returns to cr/lf rather than a
        single lf or cr (see stty(1) manpage).
        
        A quick workaround for your problem would be:
         $ echo -en 'GET / HTTP/1.0\r\n\r\n' | nc localhost 80
        
        Regards
        
        --
        Giovanni Giacobbi
        
        _______________________________________________
        Full-Disclosure - We believe in it.
        Charter: http://lists.netsys.com/full-disclosure-charter.html
        

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html