Re: multiline HTTP headers support in header()

From: Date: Thu, 03 Jul 2014 05:36:26 +0000
Subject: Re: multiline HTTP headers support in header()
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-75189@lists.php.net to get a copy of this message
On Thu, Jul 3, 2014 at 3:29 AM, Adam Harvey <aharvey@php.net> wrote: > On 2 July 2014 18:24, Solar Designer <solar@openwall.com> wrote: > > On Thu, Jul 03, 2014 at 02:09:05AM +0100, Andrea Faulds wrote: > >> On 3 Jul 2014, at 02:05, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > >> > So IE violates the RFC by misparsing the multiline headers? I'd say > it's > >> > an one more reason to never use IE :) RFC 7230 indeed proposes to > remove > >> > this capability, but it's not accepted yet, as far as I can see. We > can > >> > probably drop this immediately for 5.6, for previous versions I'm not > >> > sure if anybody uses this feature. So if anybody knows any use of it, > >> > please tell, otherwise it's probably a good idea to kill it for stable > >> > versions too. > >> > >> As I?ve had to implement HTTP myself for a particular non-PHP > application, I?ve read the original HTTP/1.1 RFC. As far as I know, > multi-line headers are semantically equivalent to single-line headers, so > couldn?t we just ?flatten? them automatically? It shouldn?t break anything > unless you?re deliberately misusing header(). > > > > I think we could, and your analysis looks correct to me, but I see no > > good enough reason to go for the extra complexity. Having a function > > defined in a more complicated manner and implemented with more code is > > asking for more bugs and mis-interactions. > > I'd tend to agree: if we're going to do this, let's just rip the > band-aid off completely. I've got a quick and dirty patch at > > > https://github.com/LawnGnome/php-src/compare/remove-multiline-headers?expand=1 > that does this, and applies cleanly against every branch from 5.4 to > master. > > I'm not so sure about the versions this should be applied too, though: > my current inclination is to only apply it to master and maybe 5.6 if > the RMs agreed. While it's a very, very small BC break (and hence one > I'm OK with in a minor branch like 5.6), I don't think we should do > this in a 5.4 or 5.5 point release — recent history (the unserialize() > hack) suggests that it's a nightmare to document and explain those > sorts of breaks. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > If I'm reading this correctly this would reintroduce https://bugs.php.net/bug.php?id=60227 those checks aren't there to support header splitting but to prevent them, as "\r\n" isn't the only separator which will cause browsers to split the header. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#75189) next »