Saxon » SaxonJS

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?

So I'm thinking that in my last example I probably meant response headers, not request headers. As I definitely wasn't constructing Link headers in a request :)

Right now I cannot setup or find a server that would respond with multiple Link headers, but I'm pretty sure I meant that in such case all response headers (of the same name) except the first one are ignored in $response?headers?link. Maybe you can see in the code whether that could be the case?

Why would a map(xs:string, xs:string*) datatype not be appropriate? For both request and response ?headers. I would much prefer the value as a sequence than single string as a comma separated list. That would be a more structured approach?

ChatGPT wrote an HTTP server for me so I could double-check the behaviour. Higher-level HTTP frameworks only allow setting headers as maps so I had to go for http.server which allows writing raw response headers.

Response headers as seen in the browser's Network tab:

Link: <https://example.com/page1>; rel="next"
Link: <https://example.com/page2>; rel="prev"

SaxonJS 2.6 output:

?headers?link: <https://example.com/page1>; rel="next", <https://example.com/page2>; rel="prev"

So I was wrong in my previous comment:

all response headers (of the same name) except the first one are ignored

?headers?link does not ignore values - both header values are present - but concatenated into a single string. So this is not a bug but a feature request:

Why would a map(xs:string, xs:string*) datatype not be appropriate? For both request and response ?headers. I would much prefer the value as a sequence than single string as a comma separated list. That would be a more structured approach?

So in this case I would expect a sequence with 2 values:

?headers?link = ('<https://example.com/page1>; rel="next"', '<https://example.com/page2>; rel="prev"')

JAX-RS Response::getHeaders uses the same kind of contract - the return type is MultivaluedMap<K,V> extends Map<K,List<V>>.