- From: James Greene <james.m.greene@gmail.com>
- Date: Fri, 20 Sep 2013 00:05:03 -0500
- 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>
- Message-ID: <CALrbKZhUWKg+e5mo1NeJaKtHfHdb3_M1RoOkn5tmSyFoZoUJgA@mail.gmail.com>
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