search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
486 stars 46 forks source link

Add server-content-type-payload #524

Closed csarven closed 1 year ago

csarven commented 1 year ago

This change adds a new feature as per https://www.w3.org/2021/Process-20211102/#class-4 :

Add requirement for server to include Content-Type in messages with payload in Solid Protocol.

Server including Content-Type in the response of a message including a payload is not guaranteed as per RFC 7231 since the inclusion is a SHOULD. It follows that the response may trigger the client to do MIME type sniffing. This requirement will ensure that server will have awareness of the media type of the message with a MUST, and clients to follow the provided Content-Type.

Moreover, the Solid Protocol requires that clients MUST include the Content-Type in PUT, POST, PATCH requests. It does not however necessarily follow that the server will preserve the media type (or its alternatives). Lastly, while a storage may potentially include resources that were not initially provided by a client - in which case the interaction is technically out of scope of Solid Protocol - this server requirement will ensure that HTTP messages will indeed include a Content-Type irrespective to however resources became available from a storage.

Preview | Diff

damooo commented 1 year ago

Yes, it would allow to not depend on many insecure ways to mime-guess.

elf-pavlik commented 1 year ago

I understand that this only applies to GET. I would like to consider extending the requirement to also require it for HEAD. I work on implementing support for Non-RDFSources and would like to be able to find the Content-Type without doing full GET. The use case would be for example in the list of file attachments to show relevant icons based on the MIME type before the user decides to download any of the attachments.

csarven commented 1 year ago

With the proposed requirement, HEAD will be covered:

The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section).

elf-pavlik commented 1 year ago

What do you think about following RFC 9110 terminology?

https://datatracker.ietf.org/doc/html/rfc9110#name-changes-from-rfc-7231

The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)

https://datatracker.ietf.org/doc/html/rfc9110#name-head

The HEAD method is identical to GET except that the server MUST NOT send content in the response. HEAD is used to obtain metadata about the selected representation without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications.

https://datatracker.ietf.org/doc/html/rfc9110#section-6.4.1

Responses to the HEAD request method (Section 9.3.2) never include content; the associated response header fields indicate only what their values would have been if the request method had been GET (Section 9.3.1).

csarven commented 1 year ago

Merging as per 2023-05-17 consensus: https://github.com/solid/specification/blob/main/meetings/2023-05-17.md#add-server-content-type-payload