Blob name
TerjeBr opened this issue · 5 comments
When the responseType is blob, should not the resulting blob that is returned as a reponse have the property "name" set from what is in the http header "Content-Disposition"?
Is this something you could consider adding to the standard?
Heya! Couple things:
- We're no longer extending XMLHttpRequest's features. If you want new features, please ask in whatwg/fetch. Having said that, it has the same "issue".
- That's a
File, not aBlob(the latter has no name field). - It's not entirely clear to me if we should offer this, or a more convenient way to parse
Content-Disposition(which I assume is the main problem) so that you can also get this name easily with other representations.
Hi.
So when the response has a "Content-Disposition" header that says it is an attachment, with a fileName, the response data could be a File instead of a Blob.
I think that could be a very nice and intuitive way to handle that http header.
This would also make it more consistent with how browsers handle the "Content-Disposition" header.
If a browser finds this header in a HTTP response, it opens a save file dialog instead of trying to display the content as a web-page. In the same way, when you do an xhr request, if the requestType is blob, you should get a File instead of a Blob if the "Content-Disposition" header is present (and is attachment instead of inline)
How can I raise this as an issue in whatwg/fetch? I am not familiar with fetch syntax.
Sure, I understand how it could work, but I'm not sure we want to do that much special handling inside these APIs. At some point we'll have to defer to libraries for those kind of niceties (though parsing the header value does seem like something reasonable to expose at some point).
For the Fetch API this would affect the ultimate return value of the blob() method on Response objects.