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 04:11:02 UTC