Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75185
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain openwall.com designates 195.42.179.200 as permitted sender)
Date: Thu, 3 Jul 2014 05:20:40 +0400
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>, D0znpp <d0znpp@onsec.ru>
Message-ID: <20140703012040.GA12971@openwall.com>
References: <20140703003646.GA12662@openwall.com> <53B4AC6E.5050401@sugarcrm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53B4AC6E.5050401@sugarcrm.com>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [PHP-DEV] multiline HTTP headers support in header()
From: solar@openwall.com (Solar Designer)

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