On Apr 5, 2013, at 3:17 PM, Alexey Proskuryakov wrote:
>
> 03 апр. 2013 г., в 13:11, Arun Ranganathan написал(а):
>
>>> My only concern is that blob.type should never contain parameters.
>>> Comparing it to "text/plain" or "image/jpeg" should work, and not
>>> mysteriously fail a year later
03 апр. 2013 г., в 13:11, Arun Ranganathan написал(а):
>> My only concern is that blob.type should never contain parameters.
>> Comparing it to "text/plain" or "image/jpeg" should work, and not
>> mysteriously fail a year later when somebody eventually throws a MIME type
>> parameter into th
On Mar 19, 2013, at 8:52 PM, Glenn Maynard wrote:
> On Tue, Mar 19, 2013 at 1:41 PM, Arun Ranganathan wrote:
>
> > 2.Convert every character in relativeContentType to lower case.
>
> I recommend referencing "Converting a string to ASCII lowercase" in HTML.
> http://www.whatwg.org/specs/w
On Tue, Mar 19, 2013 at 1:41 PM, Arun Ranganathan wrote:
> Stricter rules are in place for "type" both while constructing Blob and
> for slice calls:
>
> http://dev.w3.org/2006/webapi/FileAPI/#constructorBlob
>
> and
>
> http://dev.w3.org/2006/webapi/FileAPI/#slide-method-algo
>
> 2.Convert
Alexey,
On Mar 7, 2013, at 3:02 PM, Alexey Proskuryakov wrote:
>
> The current File API spec seems to have a mismatch between type in
> BlobPropertyBag, and type as Blob attribute. The latter declaratively states
> that the type is an ASCII lower case string. As mentioned by Glenn before,
>
On Mar 7, 2013, at 7:19 PM, Glenn Maynard wrote:
> Chrome, at least, throws on new Blob([], {type: "漢字"}), as well as
> lowercasing the string.
>
Stricter rules are in place for "type" both while constructing Blob and for
slice calls:
http://dev.w3.org/2006/webapi/FileAPI/#constructorBlob
On Fri, Mar 8, 2013 at 3:43 AM, Anne van Kesteren wrote:
> On Thu, Mar 7, 2013 at 6:35 PM, Arun Ranganathan
> wrote:
> > But I'm not sure about why we'd choose ByteString in lieu of being strict
> > with what characters are allowed within DOMString. Anne, can you shed
> some
> > light on this?
On Thu, Mar 7, 2013 at 6:35 PM, Arun Ranganathan
wrote:
> But I'm not sure about why we'd choose ByteString in lieu of being strict
> with what characters are allowed within DOMString. Anne, can you shed some
> light on this? And of course we should eliminate CR + LF as a possibility
> at constr
As an aside, I'd recommend minimizing normative dependencies on RFC2046.
Like many RFCs it's an old, unclear spec.
On Thu, Mar 7, 2013 at 12:35 PM, Arun Ranganathan
wrote:
> At some point there was a draft that specified *strict* parsing for
compliance with RFC2046, including tokenization ("/") a
The current File API spec seems to have a mismatch between type in
BlobPropertyBag, and type as Blob attribute. The latter declaratively states
that the type is an ASCII lower case string. As mentioned by Glenn before,
WebKit interpreted this by raising an exception in constructor for non-ASCII
On Mar 6, 2013, at 7:42 PM, Glenn Maynard wrote:
On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren wrote:
On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote:
> Blob.type is a MIME type, not a Content-Type header. It's a string of
> codepoints, not a series of bytes. XHR is a protocol-level
On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren wrote:
> On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote:
> > Blob.type is a MIME type, not a Content-Type header. It's a string of
> > codepoints, not a series of bytes. XHR is a protocol-level API, so
> maybe it
> > makes sense there, but
On Wed, Mar 6, 2013 at 5:47 PM, Darin Fisher wrote:
> So the intent is to allow specifying attributes like "charset"? That sounds
> useful.
Yeah I thought so. The value would be feeded straight there when
reading as if it was an HTTP response. Arun would know for sure
though.
--
http://anneva
On Wed, Mar 6, 2013 at 6:29 AM, Anne van Kesteren wrote:
> On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote:
> > Blob.type is a MIME type, not a Content-Type header. It's a string of
> > codepoints, not a series of bytes. XHR is a protocol-level API, so
> maybe it
> > makes sense there, but
On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote:
> Blob.type is a MIME type, not a Content-Type header. It's a string of
> codepoints, not a series of bytes. XHR is a protocol-level API, so maybe it
> makes sense there, but it doesn't make sense for Blob.
It's a Content-Type header value an
On Wed, Mar 6, 2013 at 3:22 AM, Anne van Kesteren wrote:
> Okay, so given https://bugs.webkit.org/show_bug.cgi?id=111380 I think
> we should put at least minimal restrictions on Blob's constructor
> concerning Blob.type. We made it "anything goes" because in theory
> with Content-Type anything go
Okay, so given https://bugs.webkit.org/show_bug.cgi?id=111380 I think
we should put at least minimal restrictions on Blob's constructor
concerning Blob.type. We made it "anything goes" because in theory
with Content-Type anything goes. But of course that is false and we
should have noticed that at
17 matches
Mail list logo
