Hi!
Our header() function supports multiline HTTP headers, which are allowed
by RFC 2616. However, newer RFC -
https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
says:
Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
(Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to
the obs-fold rule) unless the message is intended for packaging
within the message/http media type.
So, my question is - any objections for dropping this functionality? I'd
be inclined to drop it in all versions from 5.4 up since it may still be
confusing some not too smart clients that don't implement full spec, and
frankly to me it doesn't seem of any use anyhow, but if you disagree,
please explain.
Stas Malyshev
smalyshev@gmail.com
Hi!
Our
header()function supports multiline HTTP headers, which are allowed
by RFC 2616. However, newer RFC -
https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
says:Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
(Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to
the obs-fold rule) unless the message is intended for packaging
within the message/http media type.So, my question is - any objections for dropping this functionality? I'd
be inclined to drop it in all versions from 5.4 up since it may still be
confusing some not too smart clients that don't implement full spec, and
frankly to me it doesn't seem of any use anyhow, but if you disagree,
please explain.
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
--
Regards,
Mike
Hi all,
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
I don't expect there is such web server, but \r\r is allowed by this code.
I remember that there was mail server treats \r\r as double end of lines...
Perhaps, improve it?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749
I'm not sure what you meant by "that", but the code you linked to allows
multi-line headers according to RFC 2616 - this is what comment in line
750 means. I propose to remove this (of course, no newline chars will be
allowed too as they are allowed only to support RFC 2616).
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749I'm not sure what you meant by "that", but the code you linked to allows
multi-line headers according to RFC 2616 - this is what comment in line
750 means. I propose to remove this (of course, no newline chars will be
allowed too as they are allowed only to support RFC 2616).
How about replacing \r and \n with spaces and throwing E_DEPRECATED instead?
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi!
How about replacing \r and \n with spaces and throwing
E_DEPRECATED
instead?
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.
--
Stas Malyshev
smalyshev@gmail.com
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.
Agreed with this approach.
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.Agreed with this approach.
Sure, I pointed it out as it's the alternative the RFC itself suggests
it for anything but the sender. One could argue if the sender is the
application or PHP itself.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi!
Don't we prevent that already?
http://lxr.php.net/xref/PHP_5_6/main/SAPI.c#749I'm not sure what you meant by "that", but the code you linked to allows
multi-line headers according to RFC 2616 - this is what comment in line
750 means. I propose to remove this (of course, no newline chars will be
allowed too as they are allowed only to support RFC 2616).
Ha, "that" was exaclty what I meant, sorry then, and +1. :)
--
Regards,
Mike
Hi Stas,
On Wed, Feb 4, 2015 at 4:24 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
So, my question is - any objections for dropping this functionality? I'd
be inclined to drop it in all versions from 5.4 up since it may still be
confusing some not too smart clients that don't implement full spec, and
frankly to me it doesn't seem of any use anyhow, but if you disagree,
please explain.
I think you mean remove it all.
+1
Otherwise, add \r\r rejection code.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Wed, Feb 4, 2015 at 8:24 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Our
header()function supports multiline HTTP headers, which are allowed
by RFC 2616. However, newer RFC -
https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
says:Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
(Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to
the obs-fold rule) unless the message is intended for packaging
within the message/http media type.So, my question is - any objections for dropping this functionality? I'd
be inclined to drop it in all versions from 5.4 up since it may still be
confusing some not too smart clients that don't implement full spec, and
frankly to me it doesn't seem of any use anyhow, but if you disagree,
please explain.
I'm +1 on dropping this. IIRC IE does not (or at least did not) support
this as well, so our header injection protection is broken for users of IE.
Nikita