# removing http line folding support? - Thread: https://externals.io/message/81776 - Original archive: https://news-web.php.net/php.internals/81776 - Started by Stanislav Malyshev on 2015-02-04T07:24:54+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #81776 — Stanislav Malyshev — 2015-02-04T07:24:54+00:00 URL: https://externals.io/message/81776#81776 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 --- ## #81780 — Michael Wallner — 2015-02-04T08:22:24+00:00 URL: https://externals.io/message/81776#81780 · In reply to: #81776 > 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 --- ## #81781 — Yasuo Ohgaki — 2015-02-04T08:41:08+00:00 URL: https://externals.io/message/81776#81781 · In reply to: #81780 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 --- ## #81782 — Yasuo Ohgaki — 2015-02-04T08:44:48+00:00 URL: https://externals.io/message/81776#81782 · In reply to: #81776 Hi Stas, On Wed, Feb 4, 2015 at 4:24 PM, Stanislav Malyshev 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 --- ## #81783 — Stanislav Malyshev — 2015-02-04T08:52:57+00:00 URL: https://externals.io/message/81776#81783 · In reply to: #81780 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 --- ## #81785 — Matteo Beccati — 2015-02-04T09:01:42+00:00 URL: https://externals.io/message/81776#81785 · In reply to: #81783 > Hi! > > > […] > > 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). How about replacing \r and \n with spaces and throwing `E_DEPRECATED` instead? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #81787 — Stanislav Malyshev — 2015-02-04T09:03:23+00:00 URL: https://externals.io/message/81776#81787 · In reply to: #81785 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 --- ## #81788 — Michael Wallner — 2015-02-04T09:04:55+00:00 URL: https://externals.io/message/81776#81788 · In reply to: #81783 > Hi! > > > […] > > 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). > Ha, "that" was exaclty what I meant, sorry then, and +1. :) -- Regards, Mike --- ## #81798 — Nikita Popov — 2015-02-04T09:45:11+00:00 URL: https://externals.io/message/81776#81798 · In reply to: #81776 On Wed, Feb 4, 2015 at 8:24 AM, Stanislav Malyshev 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 --- ## #81807 — Leigh — 2015-02-04T10:58:02+00:00 URL: https://externals.io/message/81776#81807 · In reply to: #81787 > > I'd rather not mangle supplied data in such sensitive area. If it's > wrong, then it's wrong. Agreed with this approach. --- ## #81810 — Matteo Beccati — 2015-02-04T11:16:17+00:00 URL: https://externals.io/message/81776#81810 · In reply to: #81807 > > > […] > > 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/