Handle Content-Type parameter

[csarven]

https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1

---

When a Content-Type includes a parameter, for example charset, this errors:

https://github.com/solid/node-solid-server/blob/b84789ab03803fff9d7391ad802a9014387716fa/lib/handlers/put.js#L15-L17

Loss of media-type parameters:

https://github.com/solid/node-solid-server/blob/b84789ab03803fff9d7391ad802a9014387716fa/lib/utils.js#L251-L254

[bourgeoa]

@csarven https://github.com/solid/node-solid-server/blob/b84789ab03803fff9d7391ad802a9014387716fa/lib/utils.js#L251

[kjetilk]

Ah, the error message confused me also, my interpretation of that is that the message body has invalid text/turtle, but what this actually should say is that "Only text/turtle is supported for RDF" or something like that.

In the case above, the message body was empty, so it was certainly possible.

@bourgeoa right, but it doesn't appear that that function is actually used by the handler. So that seems to be the problem indeed.

[csarven]

getContentType shouldn't remove parameter. If the intention is to get only the type/subtype, then another function name may be more clear.

[csarven]

@kjetilk "Only text/turtle is supported for RDF" wouldn't be accurate either because as it stands, NSS's rejection of the request may be due to the fact that the media-type value includes a parameter (eg. charset).

I think the server should accept Content-Type with parameters. If the server wants to process the message body in context of the parameter, it can do that separately.

[bourgeoa]

getContentType shouldn't remove parameter. If the intention is to get only the type/subtype, then another function name may be more clear.

It can be changed. Have you a better proposal ?

[kjetilk]

@csarven: yeah, but the intention of that if is to check for actual media type, and then it would be more clear.

@bourgeoa: I would return an object, where the media type is one property and parameters are other properties, but that wouldn't be backwards compatible I guess. Perhaps it could return an array where the first element is the media type and then parameters as other elements in the array?

[bourgeoa]

@kjetilk NSS is a filesystem implementation, with contentType stored in filename extension as mimeType. Are there any use of parameters that are not stored ? I suppose that is why the function was created like that.

[kjetilk]

@kjetilk NSS is a filesystem implementation, with contentType stored in filename extension as mimeType. Are there any use of parameters that are not stored ? I suppose that is why the function was created like that.

I suppose that NSS would like to make sure that everything it stores is UTF-8. Turtle is a special case, since it is required to be UTF-8 by its spec, but thinking generally, I would think that the server might want to re-encode a body before to UTF-8 if it isn't coming in as UTF-8.

[kjetilk]

I just had a look over the specs again. Turtle says:

The media type of Turtle is text/turtle. The content encoding of Turtle content is always UTF-8. Charset parameters on the mime type are required until such time as the text/ media type tree permits UTF-8 to be sent without a charset parameter.

The problem that I think that this was intended to address was that RFC2046 required the default charset for any text/ media type to be US-ASCII (oh, the horror!). Then, RFC6657 came along to say that:

Each subtype of the "text" media type that uses the "charset" parameter can define its own default value for the "charset" parameter, including the absence of any default.

which Turtle does. So, it seems that it is now legitimate for a client to skip sending the charset parameter, but RFC6657 was published before the Turtle Recommendation, so I'm not quite sure why they formulated it like that, perhaps to satisfy the SHOULD further down in the RFC.

So, in conclusion, it is really important that NSS doesn't reject a request with a query parameter. It is currently not so important to record the charset parameter, but it should do so to ensure that all files are written with UTF-8 in case a client specifies something else.