On Sat, Aug 1, 2015 at 5:22 AM, Mickaël Rémond <mrem...@process-one.net> wrote:
> ok, I think I missed you point there, then. Do you mean the information
> passed in the slot request on XMPP should pass generic extra values that can
> be use in header by XMPP server component, like Content-MD5 header ?
That's what I was thinking indeed; of course, Content-MD5 in
particular would require that clients had some sort of support for it,
so it's sort of a separate issue.
A better example might be something like an oauth token, so the server
could generate a PUT URL and a one time use oauth token, and pass
down:
<header name="Authorization">Bearer sometoken</header>
and the client would construct the PUT request with the header:
Authorization: Bearer sometoken
If Content-MD5 were to be supported in particular it would probably
have to be something that clients supported, eg.
<header name="Content-MD5" />
without a text node might trigger clients which support it to send an
appropriate header. Of course, this would mean that clients have to
support a list of such headers (I can't think of any others, but I'm
sure there are other headers like this which require that the client
generate the actual header content), and that feels poor to me.
If you're going to try and implement a version of your spec with
headers and test it against a particular service, I recommend AWS S3
(I've been using it as an example as it's probably the most common
large file storage solution [citation needed]).
I have a branch of Daniel's reference component with S3 support here:
https://github.com/SamWhited/HttpUploadComponent/tree/s3_support
though w/o generic header support it's a bit brittle and requires
changes to Conversations
(https://github.com/SamWhited/Conversations/tree/http_upload_s3_support)
to work properly.
—Sam
--
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
