Re: multiline HTTP headers support in header()
| From: | Solar Designer | 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