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.

@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.

I have done a bit of checking and I'm not really sure I understand this issue.

As far as I see curl API offers API only for reading the whole response or headers line (CURLOPT_HEADERFUNCTION) if you are talking about response headers. In terms of request headers, it just sends what's provided which is fine. The part of the quoted RFC is about parsing the actual header value and this is not provided at all so I don't see any problem there.

In terms of stream API, it also provides only header line which is removing the trialing spaces. All of this is optional and it is also fine that it can get removed.

It is possible that I'm misunderstanding your request so please clarify with examples what issues you see and how it contradicts to the RFC. Don't forget that the RFC is talking about extracting the actual value, not processing the header line.

we should truncate single space between Colon and header value

about this I have no idea why we should be doing it. This is even recommended in RFC to keep - a single SP preceding the field-value is preferred for consistent readability by humans...?

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.