[Standards] LAST CALL: XEP-0363 (HTTP File Upload)

Sam Whited sam at samwhited.com
Tue Dec 12 22:08:52 UTC 2017


On Tue, Dec 12, 2017, at 15:49, Ruslan N. Marchenko wrote:
> Yes, I don't like the approach with wide open PUT limited by certain 
> high-level content constraints and (luckily) headers in the latest
> revision.
> At least content hash (as in jingle) would be beneficial. Shall we say 
> slot path element (public one) should be content hash (and hence part of 
> request)?
> That allows all 3 parties (sender, mediator, receiver) to verify somehow 
> validity of the content. Otherwise there's possibility of the content 
> injection.

The PUT is not necessarily wide open: that's a matter of service policy.
The addition of required headers means that you could require the PUT to
contain a token that is unique to the specific upload slot being
requested.
Since there are no interoperability concerns if different servers
implement this in different ways no specific mechanism needs to be
mandated by this spec.

You may not always know the content hash up front, and it may not be
desirable to read large files twice (first to generate the hash, the
second time to actually send the file to the server).

—Sam


More information about the Standards mailing list