This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, it is possible to use a Blob to mint a File object using a File constructor. A File is essentially a Blob with a name. The file's name should be used in "Save As" behavior in browsers. This might include use of Content-Disposition as an additional part of the blob:scheme's request-response semantics, or perhaps the specification need not mention Content-Disposition at all (since this could be an internal implementation mapping) and simply say that the file's name should be used in "Save As" functionality.
It should at least be clear that this applies to all the things that Content-Disposition filenames apply to. That could be done by defining this in terms of Content-Disposition. For example, in Chrome, clicking an <a href=blobURL> which points to data that can't be viewed inline causes it to be saved to disk without asking the user for a filename, resulting in UUID filenames. This should apply there too.
Currently, you can only really set the Content-Type response header (by way of setting the type attribute on Blob and File objects). But, you can't set the Content-Disposition, and do things like "inline" or "attachment". We did discuss this a while ago: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0372.html I propose that we specify that for File objects, we should also send a Content-Disposition *in addition* to a Content-Type, using the filename only (leaving "inline" and "attachment" out of it). The other alternative is to add yet another dictionary member (and Blob attribute) for content-disposition, to be supplied along with the Blob constructor. That seems like overkill. Content-Disposition wasn't even really an HTTP/1.1 thing (it was sort of a corollary), and had security implications that I'm not sure we'd like to dredge up again.
Just to clarify Comment 2, I meant that user agents return headers of the sort Content-Disposition: inline; filename="file.name" Where "file.name" is the filename from the File object. UAs would do this specially for File objects retrieved with blob: URLs. The API wouldn't allow header-based configuration of "Save As" behavior by allowing web developers to add "attachment" as an option for the header (since this would mean an additional property on Blob, and an additional member to the configuration/invocation dictionary for constructor calls). The alternative is to add another attribute on Blob, and to allow it to be set in the constructor. Is it worth allowing programmatic manipulation of "Save As" through a header? I'm inclined to not allow it.
I didn't mean that it should be possible to set the Content-Disposition header directly. What I meant was that we should define this in terms of what Content-Disposition does. For example, something like "user agents should determine the preferred filename of the resource as though it was a network request that had a Content-Disposition with a filename of .name". This avoids this being a narrow special case for particular UIs ("save as dialogs should use this as the default filename"), so it's clear that this should apply everywhere a content-disposition would apply. (It could actually be exposed as a real Content-Disposition header, eg. through XHR, but it doesn't have to be. It's just the behavior we're looking to hook into.)
OK, fixed, per suggestions in Comment 4. http://dev.w3.org/2006/webapi/FileAPI/#processing-media-types
[[ If a resource identified with a blob: URL is a File object, user agents must use that file's name attribute, as if the response had a Content-Disposition header with the filename parameter set to the File's name attribute [RFC6266]. ]] This seems good. [[ In particular, "File Save As" behavior must use the File's name attribute as the default name to save the file as. ]] This seems bad. It's a different requirement than the first, but we actually only want the first, I think. If you intended this sentence to be non-normative describing the implications of the first requirement, then don't use 'must' here. I suggest you remove the second sentence and maybe add a note like "This means that 'File Save As' takes the File's name attribute into account for the default name to save the file as." or some such.
Right. Browsers aren't required to use C-D filenames: they may ignore or adjust them for security or practical reasons ("C-D: lpt1", "C-D: .."), and specs typically don't try to normatively specify browser-specific UI like "save as dialogs".
OK, done along the lines of Comment 6 and Comment 7, with "must" clause removed and following note added: "Note A corollary to this is an optional implementation guideline: that the "File Save As" user interface in user agents takes into account the File's name attribute if presenting a default name to save the file as." http://dev.w3.org/2006/webapi/FileAPI/#processing-media-types
Could we expand the guideline beyond Save As...? For example, there's the case where I'm viewing a page containing an img with a blob URL src and the Blob referenced by the URL is a File. If I drag that image to my desktop, it would be nice if the name of the resulting file in the filesystem took into account the File object's name attribute. Maybe something like: "Note A corollary to this is an optional implementation guideline: that user agents take into account the File's name attribute when copying the File's data to outside the user agent and a name for the data is needed, such as the default name in a Save As... dialog or the name used when saving the data without prompting the user for a name (for example, dragging an image to the desktop)."
The note doesn't need to enumerate all possible ways in which C-D can have an effect. The note doesn't really need to be there at all, removing it wouldn't change the meaning of the spec. It's just there to help the reader follow what the previous requirement is about. That said, the note shouldn't use the word 'optional' since that's also an RFC2119 keyword. Otherwise it looks OK to me.
(In reply to brmatthe from comment #9) > Could we expand the guideline beyond Save As...? For example, there's the > case where I'm viewing a page containing an img with a blob URL src and the > Blob referenced by the URL is a File. If I drag that image to my desktop, it > would be nice if the name of the resulting file in the filesystem took into > account the File object's name attribute. Maybe something like: > > "Note > > A corollary to this is an optional implementation guideline: that user > agents take into account the File's name attribute when copying the File's > data to outside the user agent and a name for the data is needed, such as > the default name in a Save As... dialog or the name used when saving the > data without prompting the user for a name (for example, dragging an image > to the desktop)." This would be nice user agent behavior and is a great suggestion. I recommend filing respective browser bugs e.g. pick File Handling for Firefox: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox (WebKit, Chromium, Chromium with cr-blink for Blink all have similar bug databases). An API spec. stops just short of this kind of prescription, and so this is no longer under the purview of the File API. (In reply to Simon Pieters from comment #10) > That said, the note shouldn't use the word 'optional' since that's also an > RFC2119 keyword. Otherwise it looks OK to me. OK, I've removed 'optional' and marked it a non-normative guideline in the note. RFC2119 formalism expunged!