[Standards] XEP-0363 and Message MIME content type

Anurodh Pokharel info at monal.im
Fri Jan 29 18:13:53 UTC 2016

Thanks, I think out of band data on messages is an easy solution.

HEAD is part of the HTTP spec but is not uncommon for it to be blocked on
server configurations. Additionally,  depending on the way the media is
served (e.g. via a script that hides the actual path) you may not actually
get any info from the server.

I really think we should include a recommended means of transmitting
metadata in the upload XEP. This is one of those things thats only useful
if clients standardize on the way they communicate.  Including the URL in
the message body bothers me. Specifically, writing clients that
automatically call HEAD on any URL received should be explicitly
discouraged because of how easily that feature can be abused to expose a
target's IP address.


On Fri, Jan 29, 2016 at 12:09 PM, Kim Alvefur <zash at zash.se> wrote:

> 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
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160129/24df2773/attachment-0001.html>

More information about the Standards mailing list