Normally this isn't a problem, but it breaks S3-like signature verification, where client and server sign properties of a request (e.g. the Content-type header).

Elaborate, please.

Changing this arbitrarily seems just as likely to break other people (and lots of tests!). We would need a very good reason to change this.

The scenario is a golang client (e.g. https://github.com/ncw/rclone/) makes a request to a Jetty server. They both use AWS S3-like signatures to authenticate the request. I.e. both the client and server compute a hash using various request headers and sign the hash with a shared "secret" to produce a signature.

The client signature includes Content-type "text/xml; charset=utf-8" but Jetty (wrongly, IMO) normalizes the charset so the servlet sees "text/xml; charset=UTF-8". This causes the signatures to not match.

This can be worked around with some Jetty hacking, e.g. to preserve the original Content-type, but as the link above shows the official spellings of the charset is "UTF-8", not "utf-8", so seems preferable to use that.

But you could argue that http://www.iana.org/assignments/character-sets/character-sets.xhtml does say "However, no distinction is made between use of upper and lower case letters", so if you really don't want to change golang types.go I guess that's not unreasonable.

@ncw, can you elaborate? What's at fault, here? Is the "S3-like" signature algorithm just poorly designed? Is this a specified protocol, or something that rclone invented?

Just to be clear I'm not saying anything is at fault. Well, except maybe Jetty, it should not normalize the "charset" in the request header "Content-type".

The S3 authentication protocol
http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html requires the client and server to use the exact same Content-type value when computing the signature.

That's not possible when a golang client sends ...;charset=utf-8 to an S3-compatible server based on Jetty, which quietly changes the header value to ...;charset=UTF-8.

Of course this can (and should) be fixed or worked around in the Jetty server. I'm not saying golang is wrong to use "utf-8", just that it might as well use the official charset spelling "UTF-8" instead. Of course, changing to that spelling now might not be worth the trouble.

Okay, then I'll close this. Changing it would break people's tests unnecessarily if the bug is in Jetty.