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

(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:
> Using the specs and the examples Thomas Broyer gave me in the previous 
> message, I came up with this.
>
> HTTP/1.1 200 Ok
> 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
>