netdev - Re: TCP: orphans broken by RFC 2525 #2.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100927080222.GA31309@gondor.apana.org.au>
Date:	Mon, 27 Sep 2010 16:02:22 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Willy Tarreau <w@....eu>
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: TCP: orphans broken by RFC 2525 #2.17

Willy Tarreau <w@....eu> wrote:
>
> Looking more closely, I noticed that in traces showing the issue,
> the client was sending an additional CRLF after the data in a
> separate packet (permitted eventhough not recommended).

Where is this permitted? RFC2616 says:

	Certain buggy HTTP/1.0 client implementations generate
	extra CRLF's after a POST request. To restate what is
	explicitly forbidden by the BNF, an HTTP/1.1 client MUST
	NOT preface or follow a request with an extra CRLF. 

Now if you want to support these broken clients it should be
as simple as doing the read that Eric suggested but with the
proviso that you only have to read one CRLF before closing.

This workaround for broken HTTP clients definitely does not belong
in the TCP stack.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html