PHP behavior for parsing http header value is not consistent across http APIs

[HeenaBansal20]

Description

The following code:
PHP behavior for parsing headers keys and header values are not consistent across PHP supported hTTP APIs.
For example: curl APIs doesnt trim leading spaces from headers key and value . " Header2 : VALUE2 " Here key ad value will have spaces in it for CURL APIs.

However for Soap APIs remove leading/trailing spaces before reading header key and value .

IMO , There should be some consistency around PHP HTTP APIs for parsing headers key and values.

header key and values should be propagated as it is provided by user by tokenizing based on ": " or ":" because few people has tendency to write space after each punctuation , so everything after ": " or ":" should be considered as value and key should be propagated as it is .

PHP Version

PHP 8.4

Operating System

Ubuntu24

[cmb69]

IMO , There should be some consistency around PHP HTTP APIs for parsing headers key and values.

Yes and no. I'd rather not mess with what third-party libraries are doing (e.g. cURL), but where we're fully in control (e.g. ext/soap), it may make sense to be consistent.

[HeenaBansal20]

@cmb69 , Thanks for replying.
As per http spec : https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.4, we should not propagate single space after colon in header value. Same is for header key where all spaces before ':' has to be removed and should be applicable for curl APIs . So before forwarding it to curl , we should truncate single space between Colon and header value . What do you think. ?

No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to
security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code
of 400 (Bad Request). A proxy MUST remove any such whitespace from a
response message before forwarding the message downstream.

A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.