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

Well, it's not rocket-science for sure but we do need to parse the part
before the ",". We need to check the encoding, we need to make sure we know
how to determine the actual length for this encoding, we need a way to not
store length if we dunno the encoding. Simple enough but has some
ramifications.

What I'm seeing here is that being able to have a Content-Length or not
seems implementation dependent. Anne is against not taking a stand yet I'm
pretty sure we cannot assume all implementations will be able to provide a
Content-Length. So it seems like we should just keep prohibiting
Content-Length.

Do I make sense?


On 20 September 2013 05:24, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Sep 19, 2013 at 8:10 PM, Julian Aubourg <j@ubourg.net> wrote:
> > Sure, what I actually meant is that you'd need to somehow pre-parse the
> data
> > URL to extract the exact length before storage. Dunno how
> > desirable/desired/common this is.
>
> I would hardly call taking the length subtracting any characters
> before the "," and applying a multiplier "parsing". You don't have to
> look at any characters after the "," at all.
>
> / Jonas
>
> > On 20 September 2013 04:58, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >>
> >> On 9/19/13 10:51 PM, Julian Aubourg wrote:
> >>>
> >>> But Content-Length is not the same as the length of the string
> >>> containing the Data URL.
> >>
> >>
> >> Sure.  It can also be a simple formula computed from that length, in the
> >> case of base64-encoded data URLs.
> >>
> >> And of course you have to subtract out the length of the parts before
> ','.
> >> None of this is all that hard to do.
> >>
> >> -Boris
> >
> >
>