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

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;
> On Thu, Jun 11, 2009 at 6:27 PM, Robert de
> Wilde<robert.de.wilde@online.nl> wrote:
>   
>> [..]
>>     
>
> No, the headers in each part are relative to the part itself. [..]
>
> [..] make a new header conveying the range of the
> part; I don't think you can reuse Content-Range in any way...
>
>   
>> [..]
>>     
>
> 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