Transforming DataTransfer.setData HTML content
Safari, Firefox and Chrome all have different behavior when handling a call
like event.clipboardData.setData("text/html", "text"):
Safari puts "text" on the pasteboard.
Firefox puts text
Chrome puts text
Is there any provision in any applicable spec that allows for such
transformation? From what I could find, Safari behavior is the only one
allowed. Did I miss something? Should the specs be changed?
Note that Firefox and Chrome implementations appear to be fairly naive. So
Firefox for example can end up with something like this when trying to repair
the string:
text
- WBR, Alexey Proskuryakov
Re: File API: Blob.type
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 the mix. Today, all browsers expose text files at
>> text/plain. If a browser a year from now decides to call text files with a
>> UTF-8 BOM "text/plain; charset=UTF-8", it'll break interop.
What specifies how a File gets its type? The only requirement I can find is
that "User agents must not attempt heuristic determination of type", which I
think implies that something like inputElement.files[0].type is always "" for a
file chosen by a user via .
Guessing MIME type from file name or metadata is always a heuristic, as not all
platforms will know that "archive.sit" means "application/x-stuffit".
At the same time, browsers do autodetect types for many files. We'll need to
autodetect when serializing a form for submission anyway, so exposing this
information a little earlier only makes sense.
I think that these concerns can be resolved by specifying what File.type is
more explicitly. The spec can just say that parameters are not allowed in the
browser chosen type.
>> Additionally, determining a blob's file type seems like the most obvious use
>> of this property, and making people say "if(blob.type.split(";")[0] ==
>> 'text/plain')" is simply not a good interface.
>
>
> OK -- you're strongly opinionated on the matter of NOT allowing a charset
> parameter. I'd like to see if implementers who had an opinion on its
> usefulness can weigh in -- Darin? Alexey?
I do not have a very strong opinion. I like the simpler API of passing
parameters through the type attribute, as it's specified currently. This also
matches XMLHttpRequest API better. And of course, keeping existing behavior
means that we won't break the web.
- WBR, Alexey Proskuryakov
Re: File API: Blob.type
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 input, and lowercasing the string. I think that this is a reasonable reading of the spec. I'd be fine with raising exceptions for invalid types more eagerly. This is the text in question: (1) > type, a DOMString which corresponds to the Blob object's type attribute. If > not the empty string, user agents must treat it as an RFC2616 media-type > [RFC2616], and as an opaque string that can be ignored if it is an invalid > media-type. This value must be used as the Content-Type header when > dereferencing a Blob URI. > (2) > type > The ASCII-encoded string in lower case representing the media type of the > Blob, expressed as an RFC2046 MIME type [RFC2046]. On getting, conforming > user agents must return the MIME type of the Blob, if it is known. If > conforming user agents cannot determine the media type of the Blob, they must > return the empty string. A string is a valid MIME type if it matches the > media-type token defined in section 3.7 "Media Types" of RFC 2616 [RFC2616]. > If not the empty string, user agents must treat it as an RFC2616 media-type > [RFC2616], and as an opaque string that can be ignored if it is an invalid > media-type. This value must be used as the Content-Type header when > dereferencing a Blob URI. It would be helpful to have the terminology corrected, and to have this generally clarified - for example, validity is mentioned here, but seems to be unused. It seems pretty clear from normative text that charset parameter is supposed to work. A non-normative example supports that too. I agree with Arun that this seems best to keep as is. However, <https://bugs.webkit.org/show_bug.cgi?id=111380> is about a different case - it's about posting multipart form data that has Blob elements with invalid media-types. I'm not even sure which spec is in charge of this behavior - I don't think that anything anywhere says that Blob.type affects media-type of posted multipart data, even though that's obviously the intention. XMLHttpRequest spec defers to HTML, which defers to RFC2388, which mentions files "returned via filling out a form", but not Blobs (which is no surprise given its age). Making Blobs only hold valid media-types would solve practical issues, but it would be helpful to know what formally defines multipart data serialization with blobs. We also previously had <https://bugs.webkit.org/attachment.cgi?id=177736&action=review> for sending non-multipart data. Back then, we determined that "Content-Type: " should be sent when the value is invalid. I'm no longer sure if that's right. For this case, XMLHttpRequest authoritatively defines the behavior, although heavily leaning on File API to decide when the type attribute is empty: > If the object's type attribute is not the empty string let mime type be its > value. Note that "mime type" is then directly used as default media-type for Content-Type header, but it's not parsed to set encoding variable. The encoding could be needed to update a charset in author provided Content-Type header field in later steps of the algorithm. This is probably not right, as Blob should know its encoding better than code that sets header fields on an XMLHttpRequest object. - WBR, Alexey Proskuryakov
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
25.10.2010, в 16:36, Boris Zbarsky написал(а): >> That may become more common when people start downloading arbitrary files, >> and storing them to disk with FileWriter. But even years ago, we've been >> getting performance bugs forcing us to ensure responseText didn't have to be >> copied for JavaScript access. > > Sure, if people access it over and over. That's fine; not copying it seems > orthogonal to what's stored... Another kind of bug reports was that memory taken by XMLHttpRequest wasn't reclaimed fast enough when the object went out of scope. Developers did notice with their typical data sets, so XMLHttpRequest with a long response string is now more likely to trigger garbage collection in WebKit. This is also not a direct proof that doubling memory usage is unacceptable, but I think that it illustrates the point about typical current data set sizes, and how the behavior on these is viewed by developers. - WBR, Alexey Proskuryakov
Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"
25.10.2010, в 15:33, Boris Zbarsky написал(а): >> People are concerned that it would require keeping two copies of the >> data around (raw bytes, and unicode text version) since it's unknown >> up-front whether "responseText", or "responseArrayBuffer" will be >> accessed. > > Note that Gecko does exactly that, and we've seen no problems with it... > It's very rare to have really large XHR bodies, for what it's worth. That may become more common when people start downloading arbitrary files, and storing them to disk with FileWriter. But even years ago, we've been getting performance bugs forcing us to ensure responseText didn't have to be copied for JavaScript access. - WBR, Alexey Proskuryakov
Re: [DOMCore] Attr
11.09.2010, в 21:17, Michael A. Puls II написал(а): > At the time, I made <http://shadow2531.com/opera/testcases/attr/suite0.html> > to test some things with Attr nodes. (Note that the description on that page > is outdated.) A few days ago, I fixed some aspects of Attr behavior in WebKit, here's a test I made: <http://trac.webkit.org/export/68258/trunk/LayoutTests/fast/dom/Attr/change-id-via-attr-node-value.html>. Opera pretty much passes it, with the minor exception of Attr.firstChild.splitText() not splitting the text node. - WBR, Alexey Proskuryakov
Re: [CORS] What constitutes a "network error"?
20.07.2010, в 14:37, Jonas Sicking написал(а): > However I haven't been able to find a clear definition of what counts > as a "network error". Does this include successful HTTP requests that > return 4xx or 5xx status codes? Or just errors in the lower level of > the stack, such as aborted TCP connections? FWIW, I've been always assuming the latter. Blocking 4xx and 5xx responses would mean having a rather unexpected difference between same origin and cross origin XMLHttpRequest (the former lets JS code see such responses). - WBR, Alexey Proskuryakov
Re: [File API] Recent Updates To Specification + Co-Editor
28.06.2010, в 15:37, Adam Barth написал(а): I believe Alexey Proskuryakov has strong feelings on this topic. I e-mailed public-webapps not long ago, but that seems to have gone unnoticed, <http://www.mail-archive.com/public-webapps@w3.org/msg09236.html >. - WBR, Alexey Proskuryakov
Re: [fileapi] urn -> URL
12.11.2009, в 0:13, Anne van Kesteren написал(а):
It would however be consistent with WebSocket.URL, type="url">, url("image"), EventSource.URL, HTMLDocument.URL, etc.
Keeping the author-facing APIs the same would be a good thing IMO.
EventSource.URL and WebSocket.URL have been renamed in the relevant
specs to lower case since this discussion, which I think is unfortunate.
1. This doesn't buy us a lot of consistency, since document.URL is
likely the most familiar of these APIs to many Web developers, and
WebSocket/EventSource now use a different case for URL.
2. As we're trying to add consistency, we should take a path that
makes us consistent with what's available on Document. One way to do
that would be to support both url and URL in some interfaces.
WebSocket, Blob and EventSource can support both URL and url if really
necessary, but adding a "url" property to documents is likely to cause
compatibility issues.
3. WebSocket.URL and EventSource.URL are already supported in shipping
implementations. I think that there should be better reasons to change
shipping APIs than we seemed to have had here.
4. Blob.url isn't shipping with any browser yet, as far as I can tell
(Firefox 3.6.3 and Opera 10.54 don't have window.Blob; WebKit has it,
but doesn't have Blob.url).
I think that WebSocket.URL and EventSource.URL should be changed back
to upper case, and Blob should use upper case, too.
- WBR, Alexey Proskuryakov
Re: [webworkers] SharedWorker and ApplicationCache
07.11.2009, в 10:47, Michael Nordman написал(а): I've been wondering if SharedWorkers should have a means of establishing an appcache similar to how pages can via the manifest='x'> mechanism. My mental model is that a shared worker is very much like a top- level page with respect to appcaches, but that means for a shared worker to express/establish its appcache is missing. Don't shared workers depend on HTML documents for network loading? I'm not sure how they can have independent caches, if they just ask a document to fetch a resource for them. - WBR, Alexey Proskuryakov
Re: [cors] Redirects
23.04.2009, в 12:54, Anne van Kesteren написал(а): I want to support redirects on simple requests (as is already done for e.g. and ) and preflight requests, but not on actual requests. This is what the specification specifies and I believe this is what WebKit implements. Not at the moment - cross-origin redirects are currently never followed for XMLHttpRequest in WebKit. I do agree that the use case of moving services to another host looks compelling enough to support these classes of redirects in some way. - WBR, Alexey Proskuryakov
Re: [XHR] Authorization header
On 01.04.2009, at 13:49, Anne van Kesteren wrote: Consistency with cross-origin requests where they need to be blocked to prevent distributed dictionary attacks. I actually thought Opera already blocked this header and the next Firefox release will do so as well. According to <http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2903 > and my testing, Firefox doesn't block it. As there seems to be no danger in allowing this header for same origin requests, I'd suggest removing it from the list of forbidden headers. As mentioned in this thread, there are valid reasons to control it explicitly. - WBR, Alexey Proskuryakov
[XHR] Authorization header
Per the current XHR spec draft, the Authorization header cannot be set from JavaScript for security reasons. As far as I know, no shipping browser blocks it - and when we started blocking it in WebKit, it caused a compatibility problem, <https://bugs.webkit.org/show_bug.cgi?id=24957 >. What is the security reason to block this header? - WBR, Alexey Proskuryakov
Re: [XHR2] Upload progress events and simple cross-origin requests
20.03.2009, в 1:52, Jonas Sicking написал(а): I don't know how easy it is with current technologies to do this reliably. Or how big chances are that we can fix those technologies in the future to not work at all, or at least be less reliable. If you have that information I can try to bring a case for security review here. The examples Ian gave all seem reliable to me. Besides, I think that my example with timing of POST requests is quite reliable. It has been repeatedly shown that timing-related checks are incredibly powerful - see e.g. <http://www.daemonology.net/hyperthreading-considered-harmful/ >. A possible counter-argument is that there is more than simple port scanning that we should worry about - with sufficient out of band information, it could be possible to precisely detect operating systems and services on the internal network, see <http://nmap.org/book/osdetect.html >. I doubt that upload progress events provide much above upload timing in this regard, but it might be that they do. - WBR, Alexey Proskuryakov
Re: [XHR2] Upload progress events and simple cross-origin requests
19.03.2009, в 21:00, Jonas Sicking написал(а): While I agree that there are other ways of doing this, I think I'd have a really hard time selling a feature that explicitly allows port scanning to our security team. Especially when there is an easy remedy. The price comes mainly in the form of developer time - first, they will be inconvenienced by arbitrary restrictions on when they can install event listeners, and then (but more significantly), they'll have to implement OPTIONS server-side, even if they didn't need it otherwise. There is also some price in performance due to making a preflight request, although I guess it's negligible in cases when upload progress events will be used. Finally, there can potentially be a compatibility problem if some proxy is not configured to pass OPTIONS requests, but I do not have any data on whether that's likely. That said, I don't care too much either way. - WBR, Alexey Proskuryakov
Re: [XHR2] Upload progress events and simple cross-origin requests
19.03.2009, в 2:48, Jonas Sicking написал(а): It can, though potentially not as reliably. And it's also something we'd like to fix. In other words, port-scanning of intranets isn't something I'd like to build into the standard. Especially when protection for it comes at a relatively low cost. Low enough that it's very doubtful authors will ever notice this. Fair enough. This brings another problem, though: scripts can POST large requests and measure how long it takes. This is quite reliable, too, so forbidding explicit progress events while keeping POST on simple method list doesn't buy much security. In fact, it seems very likely that even timing of preflight requests makes port scans possible, but I don't have any data to support this theory. - WBR, Alexey Proskuryakov
[XHR2] Upload progress events and simple cross-origin requests
Per the current XHR2 spec draft, upload progress events are not sent if the cross-origin request didn't do preflight. What is the rationale behind this requirement? I used to think that this was necessary to prevent port scans of internal networks, but that can be done via other mechanisms anyway, as far as I know. - WBR, Alexey Proskuryakov
[CORS] Preflight algorithm and content types
Per the current CORS spec draft, cross-origin request with preflight algorithm is followed if Content-Type is set, and it is not one of the three predefined types. However, the preflight algorithm itself immediately decides to skip preflight if these conditions are true: * For request method there either is a method cache match or it is a simple method. * For every header field name of custom request headers there either is a header cache match or it is a simple header. It seems that a check for content type should be added here, as well. - WBR, Alexey Proskuryakov
Re: [CORS] Charset in content type
16.03.2009, в 14:12, Anne van Kesteren написал(а):
An unrelated question about the same sentence is why the header
field value is matched case insensitively. My understanding is that
this rule was meant to prevent exposing unsuspecting servers to
requests that couldn't be made with existing mechanisms such as
form submission, and I'd be quite surprised if any major browser
used anything but lower case here.
Media types are ASCII case-insensitive. E.g. if someone does
setRequestHeader("Content-type", "TEXT/Plain")
that should just work.
The difference is that when one does , the
MIME type on the wire is "text/plain", but with setRequestHeader, it's
"TEXT/Plain". So, server-side code that does case-sensitive
comparisons (something like if (contentType == "text/plain") ... else
if (contentType == "multipart/form-data") else www-form-urlencoded>) can be fooled. I'm not saying that this is a
particularly likely a bug for servers to have, but it's also extremely
easy to protect from in CORS.
- WBR, Alexey Proskuryakov
[CORS] Charset in content type
Per the current CORS spec draft, a request can only be a simple request if, among other conditions: "Custom request headers does not contain a header field name that is an ASCII case-insensitive match for Content-Type or it does contain it and the corresponding header field value is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain." This forbids having a charset in Content-Type (e.g. text/plain; charset=UTF-8). I doubt that this limitation is necessary, and it prevents sending an XMLHttpRequest without preflight in this case. Firefox seems to always append a charset to content type, even if setContentHeader was used to specify the header explicitly, so simple requests are effectively limited to GET and HEAD as a result. WebKit currently does not do that, but will be similarly affected if a content type with charset is specified via setRequestHeader. I think that the algorithm can only compare MIME types, not the full Content-Type string. An unrelated question about the same sentence is why the header field value is matched case insensitively. My understanding is that this rule was meant to prevent exposing unsuspecting servers to requests that couldn't be made with existing mechanisms such as form submission, and I'd be quite surprised if any major browser used anything but lower case here. - WBR, Alexey Proskuryakov
Re: [selectors-api] Test Suite Missing tests for Namespace Selectors
12.03.2009, в 18:01, Boris Zbarsky написал(а): Make of this what you will. But as I recall, the change in the "XML Namespaces" section was meant precisely to ensure that in JS passing "" for all namespace URIs would work exactly like passing null. Sounds like webkit either implements createElementNS per DOM Core 2 or has a buggy DOM Core 3 impl. Thanks! I think that we want a proper DOM 3 Core implementation, filed <https://bugs.webkit.org/show_bug.cgi?id=24548>. I agree that the test should probably use null indeed. - WBR, Alexey Proskuryakov
Re: [selectors-api] Test Suite Missing tests for Namespace Selectors
12.03.2009, в 17:19, Lachlan Hunt написал(а):
WebKit has a bug with the "|foo" selector.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28
Opera and Firefox pass
This is actually a difference in createElementNS(null, "p") vs.
createElementNS("", "p") behavior. I don't know whose bug it is, but
in Firefox and Opera, empty and null namespace arguments both result
in null namespace for the created element.
When createElement(null, "p") is used, this test passes in WebKit, too.
- WBR, Alexey Proskuryakov
[XHR2] Upload events flag
What is the meaning of upload events flag in XMLHttpRequest 2? Its definition is that it "is used in the send() algorithm to determine whether upload progress events will be dispatched for non same origin requests." However, it is only set by send, and is only used for passing in cross-origin request algorithm as force preflight flag. If the current text accurately describes how this flag is supposed to work, I'd suggest an editorial change that will remove it, and say want to pass to CORS directly. However, my understanding is that it might in fact need to prevent dispatching progress events even in case a listener gets added after invoking CORS. Was that the intention? - WBR, Alexey Proskuryakov
Re: [selectors-api] Why null as opposed to empty string (or either one) to resolve default namespace
On Jul 12, 2008, at 12:20 AM, Bjoern Hoehrmann wrote: For what it's worth, it looks to me like Gecko returns the default namespace if "" is passed to lookupNamespaceURI. It's not clear to me whether that's correct per the DOM3 Core spec. It is, because it requires that for `null`, and requires to treat empty strings the same as `null` whenever namespace names are specified. WebKit returns null if "" is passed to lookupNamespaceURI. I was going to fix it, but could not find any reference to this behavior in DOM 3 Core. The closest thing I found was "In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null" - but the parameter to lookupNamespaceURI is not a namespace URI. So, it seems to me that WebKit behavior is correct by the letter of the spec. - WBR, Alexey Proskuryakov
