Re: multiline HTTP headers support in header()
| From: | Ferenc Kovacs | Date: | Thu, 03 Jul 2014 05:42:14 +0000 |
| Subject: | Re: multiline HTTP headers support in header() | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75190@lists.php.net to get a copy of this message | ||
On Thu, Jul 3, 2014 at 7:36 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>
>
> 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
>
and for the record, my irc history tells me that Nikita sent an email about
http://lab.onsec.ru/2012/08/php-multiple-headers-bypass-available.html
to
security@php.net back in 2012-08-24, so maybe there were some discussion
there which I'm missing.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu