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

Comments inline:

Thomas Broyer schreef:
> On Thu, Jun 11, 2009 at 6:27 PM, Robert de
> Wilde<robert.de.wilde@online.nl> wrote:
>   
>> 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?
>>     
>
> 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.
>   
A content-range + content-length inside of the *response* of the 
content-location (*part*) wouldn't fix that I guess?
> 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...
>   
Mm, content-range was the best I could find 'till now.
>> 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...
>
>   
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).
>> 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
Looks great! Lot of bits to read, but I'll get through it! I hope it's 
allowed within (existing) multipart messages! Thanks ..!