the Content-Language response header from mdq-server isn't always relevant

[trscavo]

The Content-Language response header might be useful when returning HTML but when the content type is application/samlmetadata+xml, a Content-Language response header is not necessary (and in fact, confusing).

[iay]

This behaviour appears to be mandated by the Java Servlet specification:

If the servlet does not set the locale before the page is committed, the container’s
default locale is used to determine the response’s locale

...

Containers must communicate the locale ... used for the servlet response’s writer
to the client if the protocol in use provides a way for doing so. In the case of HTTP,
the locale is communicated via the Content-Language header,

So, this is not something that can be changed as far as I can tell.

Note that RFC2616 says:

Content-Language MAY be applied to any media type -- it is not
limited to textual documents.

Closing this as it seems to be something we just have to put up with.

[trscavo]

I'd reopen this issue if I could. Regardless of what the software stack is capable of, the Content-Language response header just doesn't make sense in the case of SAML metadata. The only interpretation of Content-Language that makes any sense at all is the fixed value of "en-US", which is the language of the SAML metadata schema itself (typified by the use "Organization" as opposed to "Organisation" in the schema document).

So let me ask this: if the default locale of some other container were something other than "en-US", then that value would be used instead? That seems like a bug to me and regardless of what our software stack is capable of, I wonder if the protocol spec should mandate that "the Content-Language response header SHOULD be omitted" for this protocol.

[iay]

There's nothing we can do here, so it's right to close the issue here.

If you think it's an issue for the MDQ spec, that would require a ticket there. However, I'd caution you that RFC 2119 frowns on unnecessary normative language, and we'd probably be called on that if and when we got to an IETF review:

Imperatives of the type defined in this memo must be used with care
and sparingly.  In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.

So, I don't think we could or should make such a change to the MDQ spec. We'd just have to remove it again later.