Subject: How legal is this HTTP header (1.1)?

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 12:08:30 +0200

Hello,

I order to try to find a way to catch one resource partially from 
several locations I constructed this header:
http://pastebin.ca/1456435

HTTP/1.1 302 Found
Content-type: multipart/parallel; boundary="ping"
Content-length: 2048;
Accept-Ranges: bytes;

--ping
Content-Id: Part1-ID
Content-Range: bytes 0-511/2048
Content-Encoding: base64

[SomeBase64StringHere==]
--ping
Content-Id: Part2-Identifier
Content-Range: bytes 512-1023/2048
Content-Location: http://sas4.domain.ext/resource/part2
--ping
Content-Id: Part3-SomeRandom
Content-Range: bytes 1024-1535/2048
Content-Location: http://sas2.domain.ext/resource/part3
--ping
Content-Id: Part4-Reference

My question is if this Header would be accepted within the current 
specification (from HTTP 1.1?)? If not, is there any thing I could 
consider reconstructing to DO fit within the specs (and have the same 
functionality)?

Thanks in advance,

Robert de Wilde

---

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 12:14:20 +0200

Sorry, the last part was cut off! The 'complete' HTTP header:

HTTP/1.1 302 Found

--ping
Content-Id: Part1-ID

[..SomeContentWith512bytesOfLengh..]
--ping
Content-Id: Part2-Identifier
Content-Range: bytes 512-1023/2048
Content-Location: http://sas4.domain.ext/resource/part2
--ping
Content-Id: Part3-SomeRandom
Content-Range: bytes 1024-1535/2048
Content-Location: http://sas2.domain.ext/resource/part3
--ping
Content-Id: Part4-Reference
Content-Range: bytes 1536-2047/2048
Content-Location: http://sas8.domain.ext/resource/part4
--ping--

Robert de Wilde wrote:
> [..]
> [..] Lacking header [..]
> [..]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Jun 2009 13:48:19 +0200

> Content-type: multipart/parallel; boundary="ping"

No, the Content-Length determines the length of the message-body
including any multipart stuff within it.  Multipart has no impact
on parsing the overall message.  [And this is a bad use of 302.]

....Roy

---

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 18:27:25 +0200

So if not valid, what would be a better approach? Leaving out the 
content-length or setting it 0 would be valid I guess? What about the 
rest of the body. Each content-location could give back it's own 
header-informatie (like content-length), that would be good right?

What about content-location, is it valid to put content-location inside 
the multiple parts of a multipart/parallel (or related) message?

Trying to find ways within the specification.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 11 Jun 2009 18:38:32 +0200

On Thu, Jun 11, 2009 at 6:27 PM, Robert de
Wilde<[email-masked]> wrote:
> content-length or setting it 0 would be valid I guess? What about the rest
> of the body. Each content-location could give back it's own

No, the headers in each part are relative to the part itself. The
Content-Location just says that the same thing could be (have been)
obtained at that URL. The Content-Range and Content-Length would be
wrong there.

I think you'd have to make a new header conveying the range of the
part; I don't think you can reuse Content-Range in any way...

> What about content-location, is it valid to put content-location inside the
> multiple parts of a multipart/parallel (or related) message?

Given the definition of multipart/parallel, I'm not even sure you're
right in using it here...

> Trying to find ways within the specification.

How about using message/external-body;access-type=URL [1] in each part
of a new multipart/xxx message?

[1] http://tools.ietf.org/html/rfc2017

-- 
Thomas Broyer

---

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 18:58:27 +0200

Comments inline:

> obtained at that URL. The Content-Range and Content-Length would be
A content-range + content-length inside of the *response* of the 
content-location (*part*) wouldn't fix that I guess?
> part; I don't think you can reuse Content-Range in any way...
Mm, content-range was the best I could find 'till now.
> multiple parts of a multipart/parallel (or related) message?Given the definition of multipart/parallel, I'm not even sure you're
Defining some way of saying that the resource can be received 
async/parallel is my main goal, I thought this would be ok, maybe I can 
use another type then, or as you say later in your message, define a new 
one (though I don't fancy it, I'd like to keep within the existing specs 
as much as possible).
> [1] http://tools.ietf.org/html/rfc2017
Looks great! Lot of bits to read, but I'll get through it! I hope it's 
allowed within (existing) multipart messages! Thanks ..!

---

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 19:24:41 +0200

Using the specs and the examples Thomas Broyer gave me in the previous 
message, I came up with this.

HTTP/1.1 200 Ok
;   Still think multipart/parallel could be in here too :/ ?
Content-Type: multipart/alternative; boundary=ping
Content-ID: file1
;   MD5 from all parts together, being the 'file1'
Content-MD5: FileMD5String
--ping
Content-type: message/external-body;
                            access-type=URL;
                            URL="http://sas1.domain/thisfile/part1"
Content-type: text/plain
;   MD5 from this part only
Content-MD5: PartMD5String1
--ping
Content-type: message/external-body;
                            access-type=URL;
                            URL="http://sas2.domain/thisfile/part2"
Content-type: text/plain
Content-MD5: PartMD5String2
--ping
Content-type: message/external-body;
                            access-type=URL;
                            URL="http://sas3.domain/thisfile/part3"
Content-type: text/plain
Content-MD5: PartMD5String3
--ping--

Let's say I need an aggregated datafile from three different 
companies/locations, this would give me that ability? I considered  
using torrents, but as I don't want all my clients to install  torrent 
apps, this would be a much better solution! And saves a lot of bandwidth 
'cause location 2 and 3 doesn't have to send the file over to server 1 
any more, to serve it to the client requesting it. Location 2 and 3 can 
now send it directly to the client, right? No hopefully this is within 
HTTP 1.1 specs (or is it MIME spec?).

Thanks this far!

Thomas Broyer wrote;
> No, the headers in each part are relative to the part itself. [..]
>
> [..] make a new header conveying the range of the

---

From: Robert de Wilde <[email-masked]>
Date: Thu, 11 Jun 2009 19:29:10 +0200

(Sorry for this second message)

Ah, I see why multipart/parallel is not the way to go.. I thought it was 
about the retrieval of resources, but it's about the resources itself.

Robert de Wilde wrote:
> apps, this would be a much better solution! And saves a lot of 
> bandwidth 'cause location 2 and 3 doesn't have to send the file over 
> to server 1 any more, to serve it to the client requesting it. 
> Location 2 and 3 can now send it directly to the client, right? No 
> hopefully this is within HTTP 1.1 specs (or is it MIME spec?).
>
> Thanks this far!
>
>
> Thomas Broyer wrote;