Re: multiline HTTP headers support in header()

From: Date: Thu, 03 Jul 2014 01:20:40 +0000
Subject: Re: multiline HTTP headers support in header()
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-75185@lists.php.net to get a copy of this message
Hi Stas, On Wed, Jul 02, 2014 at 06:05:50PM -0700, Stas Malyshev wrote: > > Please drop multiline HTTP headers support from PHP header() because it > > was never needed in that layer, it is a security risk in combination > > Why it's not needed in that layer? If you want to send a multiline > header allowed by RFC 2616 (assuming you do want it, for undefined > reasons), how else you do that? That's the only way to send headers in > PHP as far as I can see. As you say, "for undefined reasons". I am unaware of a good reason for a PHP app to want to explicitly do that. Stretching my imagination, I'd think a valid reason would be if someone were implementing an HTTP client/proxy, and wanted to pass the received headers on to another HTTP client unaltered (including even their protocol level representation). I think PHP's header() function shouldn't be intended for such use, especially as it doesn't guarantee there are no extra headers and that the headers come in a particular order (so it's not "unaltered" anyway). In other words, PHP header() is not a sufficiently low-level interface for the existence of individual low-level features in it to matter. I think it should be a medium-level interface (so to speak), providing only the somewhat abstract functionality of "set this HTTP header to this value", without exposing the aspect of how exactly that is done. > > with a certain IE bug, IE didn't support such multiline response headers > > properly anyway, and they are deprecated by RFC 7230: > > So IE violates the RFC by misparsing the multiline headers? That's my current understanding, based on D0znpp's testing. Alexander

« previous php.internals (#75185) next »