Bug #5199
open
Multi-valued request/response headers
0%
Description
Looks like multi-values are not supported in 2.3 because headers type is map(xs:string, xs:string).
https://www.saxonica.com/saxon-js/documentation2/index.html#!development/http
Maybe the type should be map(xs:string, xs:string*)?
A similar issue to the URL param parsing: https://stackoverflow.com/questions/68944773/parsing-a-url-query-string-into-a-map-of-parameters-with-xpath
Updated by Norm Tovey-Walsh almost 2 years ago
- Sprint/Milestone set to SaxonJS 3.0
Updated by Martynas Jusevicius almost 2 years ago
Another manifestation of this is that given request headers with repeat names, for example
Link: <http://www.w3.org/ns/auth/acl#Read>; rel=http://www.w3.org/ns/auth/acl#mode
Link: <http://www.w3.org/ns/auth/acl#Write>; rel=http://www.w3.org/ns/auth/acl#mode
Link: <http://www.w3.org/ns/auth/acl#Control>; rel=http://www.w3.org/ns/auth/acl#mode
Link: <http://www.w3.org/ns/auth/acl#Append>; rel=http://www.w3.org/ns/auth/acl#mode
?headers?link seems to return only the first value:
<xsl:message>?headers?link: <xsl:value-of select="?headers?link"/>
Output:
xsl:message: ?headers?link: <http://www.w3.org/ns/auth/acl#Read>; rel=http://www.w3.org/ns/auth/acl#mode
Executing the same request as fetch in the Firefox console, I get concatenated values from all Link headers:
<http://www.w3.org/ns/auth/acl#Read>; rel=http://www.w3.org/ns/auth/acl#mode, <http://www.w3.org/ns/auth/acl#Write>; rel=http://www.w3.org/ns/auth/acl#mode, <http://www.w3.org/ns/auth/acl#Control>; rel=http://www.w3.org/ns/auth/acl#mode, <http://www.w3.org/ns/auth/acl#Append>; rel=http://www.w3.org/ns/auth/acl#mode
That seems to be the correct behavior. RFC7230 3.2.2. Field Order says:
A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.
Could this be addressed in Saxon-JS 2.x?
Please register to edit this issue
Also available in: Atom PDF Tracking page
.