An unparsed media type for "append bytes"

[awwright]

Personally speaking, I would like to see a media type whose entire semantics is "append the enclosed bytes to the target". This would likely be very useful for logging applications.

I think there would be demand for this, for example, the HTTP Resumable Uploads I-D authors asked about using a media type that would contain only the contents of the change, and enclosing the metadata for the patch body in the HTTP message itself. Some people were skeptical about registering a media type that can only be used in HTTP, but if the media semantics were simply "append these contents to the target" then no out-of-band information is needed in this case.

[TheDocTrier]

Instead of registering a new media type, we could provide end-/* or EOF-/* as a range specifier. The other-range rule suggests that expanding the ways to describe a range was somewhat expected.

[awwright]

The important feature of this proposal isn't (just) that it appends data, but that there's no need to parse it for metadata, like Content-Offset, Content-Range, or something else, inside the content. This adverts the need for a parser if your application only needs to append, which is a common case.

However regarding the syntax, the other-range production is only used within the "Range" field, which is for querying a range that may or may not exist, and notably not "Content-Range" which actually describes the message content or part content/part body.

An earlier draft of this document proposed the exact technique you describe, and personally speaking I think it is entirely compatible with how HTTP extension mechanisms are supposed to work—key words "supposed"—but several influential people in our companion HTTP WG thought it would be better for compatibility if this were a new field instead.

Thanks for the suggestion though, it's still useful to know I wasn't the only one who thought that.

[TheDocTrier]

Ah, I see. Well that discussion sounds like it will preempt a number of my comments/suggestions in #1. It's interesting to see that these ideas were present in an earlier draft.

I think my general hope was that a directive to "append" data could be made unit agnostic since it seems so close to a range specification (see here:

Other range units, such as format-specific boundaries like pages, sections, records, rows, or time, are potentially usable in HTTP for application-specific purposes, but are not commonly used in practice. Implementors of alternative range units ought to consider how they would work with content codings and general-purpose intermediaries.