W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: [XHR] Content-Length header for data: URLs

From: James Greene <james.m.greene@gmail.com>
Date: Fri, 20 Sep 2013 00:05:03 -0500
Message-ID: <CALrbKZhUWKg+e5mo1NeJaKtHfHdb3_M1RoOkn5tmSyFoZoUJgA@mail.gmail.com>
To: Julian Aubourg <j@ubourg.net>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
Just an observation — perhaps an obvious one to others who are more
familiar with the various URI specs and whatnot — but I've always
considered the comma and prior to be the equivalent of HTTP headers
(metadata) for the image, so to me the "Content-Length" would likely
exclude the comma and prior.  Does that make sense to others?

Sincerely,
    James Greene



On Thu, Sep 19, 2013 at 11:10 PM, Julian Aubourg <j@ubourg.net> wrote:

> It's a malformed data URI for now. What I'm wondering is if we're sure
> we'll never have an encoding that makes it impossible to determine the
> length without decoding the entire content (think url-encoded like).
>
> I do agree having the Content-Length is useful information, I'm just
> trying to make sure we're future-proof in our approach.
>
> My opinion is that a Content-Length "should" be provided but I'm not sure
> it "must". And again, since Anne doesn't seem to favour "should"... well,
> we're back at "must not".
>
>
> On 20 September 2013 05:55, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 9/19/13 11:39 PM, Julian Aubourg wrote:
>>
>>> We need to check the encoding
>>>
>>
>> You mean the base64 or lack thereof?
>>
>>
>>  we need to make sure we
>>> know how to determine the actual length for this encoding
>>>
>>
>> For base64 you do.  Otherwise, it's a malformed data URI.
>>
>>
>>  we need a way
>>> to not store length if we dunno the encoding
>>>
>>
>> In what situation would this ever happen?
>>
>>
>>  What I'm seeing here is that being able to have a Content-Length or not
>>> seems implementation dependent.
>>>
>>
>> No more so than having a Content-Type, as far as I can see.
>>
>>
>>  I'm pretty sure we cannot assume all implementations will be able to
>>> provide a Content-Length.
>>>
>>
>> I'm pretty sure we can in fact assume just that.
>>
>>
>>  So it seems like we should just keep
>>> prohibiting Content-Length.
>>>
>>
>> If it were useless to provide it, I might agree.  But it's useful.  This
>> is why blob URIs go out of their way to provide it...
>>
>> -Boris
>>
>
>
Received on Friday, 20 September 2013 05:05:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:13 UTC