Hi, On 01/29/2016 05:38 PM, Anurodh Pokharel wrote: > In the process of implementing XEP-0363 (HTTP file uploads > http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the > realization that it would make a lot of sense to include MIME content type > and size in the message stanza. I've done a bit of searching and I haven't > found any XEP that defines this behavior. If any of this sounds like it's > already been done, please point me in the right direction.
It does not specify how the URL is sent. I know at least one implementation just dumps it in a message <body>, which would not let you specify any additional metadata. Something like OOB <http://xmpp.org/extensions/xep-0066.html> combined with SHIM <http://xmpp.org/extensions/xep-0131.html> could carry more detailed metadata. Or Jingle FT with the HTTP transport method: <http://www.xmpp.org/extensions/xep-0370.html> > Essentially as I understand it, the issue is HTTP file uploads are designed > to solve the problem of people using dropbox or some other third party > cloud service and replace that with an XMPP server that performs all of > this internally. This is great but simply posting a link to an image or > video alone isn't very useful to the recipient. One way of resolving this > is to have the receiving client present the link or preform an HTTP HEAD > call to try to determine the media type and based on the response try to > display the content inline. The problem here are there is nothing in the > spec that requires the server serving the "attachment" to support HEAD. > There is no guarantee that every HTTP configuration would allow this call. I believe existing implementations do HEAD requests first to determine size and content type. I *think* the HEAD method is required by the HTTP specification. > At the moment, on the client, we would have to scrape the URL to try to > determine the media type (audio, video, image etc). While HEAD solves the > problem, I believe rather than require HEAD support, it may make sense to > include the content type and size in the message stanza that has the URL of > the uploaded file. This would be the same data passed to the server in the > upload request. HEAD would require 2 HTTP calls, first the HEAD to > determine MIME content type and and size and the second GET to fetch the > actual media The sender is aware of both the type and size and this allows > the receiver to determine several things from the message stanza it self: > > 1. Is it a format that can be displayed inline? > 2. Is the file small enough to download automatically? In particular, this > is a concern for mobile users. > 3. Is the file in a format that can can be streamed rather than kept in a > local cache? This would make sense for audio and video. > There are certain security considerations. Auto downloading content to > display inline must require the receiver to trust/know the sender to > prevent abuse (spam, web bugs to expose IP). Additionally, any decisions to > download content based on the content size assumes the sender is honest > about size. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
