Open Bug 662169 Opened 10 years ago Updated 5 years ago
Should set Accept header to object/@type when fetching remote object
Short WSGIREF script testing the MIME type sent by the browser when fetching a remote resource linked from an object tag
1.22 KB, application/octet-stream
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:220.127.116.11) Gecko/2011032020 Camino/2.0.7 (like Firefox/3.0.19) Build Identifier: object/@type is an optional attribute providing the MIME type of the content. When fetching a remote object and if @type is set (and a valid MIME type), Gecko should send it to the remote host. Why: Content negotiation of multi-format resources, especially between textual and image formats Use case: I was working on a floor plan demo/API, and most of the floor plan resources were to be made available in a number of formats: an HTML page for details and sub-resources, a JSON for JS code and an image for visualization. I tried to use *object[@type='image/svg+xml']* so that the server side could just return the resource in the format clients liked most, in what I understand to be a RESTful manner. Reproducible: Always Steps to Reproduce: 1. Add an object tag to a remote resource with an @type set to a valid MIME type 2. Check the Accept header for the resource Actual Results: Gecko does not seem to care for @type, and always sends the same Accept header: 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' Expected Results: Gecko uses object/@type to set the Accept header of the resource when object/@data points to a remote resource, if @type is a valid MIME type (or looks like one), do one of: * Set Accept to object/@type directly * Use @type to craft a better Accept (with correct priorities) if @type is a subtyped MIME: @type='image/svg+xml' would yield the Accept 'image/svg+xml,image/*;q=0.9,*/*;q=0.8*' * Put the content of object/@type at the front of the Accept header Attached a Python script (compatible 2 & 3) which launches a very simple WSGI application via WSGIREF. Simply browse to http://localhost:8000, it will assert if the Accept header used when requesting a resource matches the @type of the object tag which linked to this resource, and will display the header's value in red if it does not.
The thing is... we in fact accept all types in <object>, as the header says. The @type is advisory only; what we will do will depend on what type the server response with. So changing the Accept header in the ways you describe would in fact be a spec violation (esp. in cases when we don't actually support the type in @type!).
Component: Networking: HTTP → DOM: Core & HTML
QA Contact: networking.http → general
(In reply to comment #2) > The thing is... we in fact accept all types in <object>, as the header says. > The @type is advisory only; what we will do will depend on what type the > server response with. > > So changing the Accept header in the ways you describe would in fact be a > spec violation I don't see why it would be a spec violation: the Accept header is mostly advisory (I don't know a single web server or framework in which it is binding), and the browser could just tack '*/*;q=0.5' at the end of it. The only thing it would do would be providing higher-quality information to the server based on client data. > (esp. in cases when we don't actually support the type in @type!). then the @type could just be dropped — or reverted to the current behavior — as if the value was not a valid MIME type. I don't really see why that would be an issue.
Note that other browsers just send "Accept: */*" according to bug 1232583. We could certainly do that, but the only good reason to do it is to save space in the HTTP request...
You need to log in before you can comment on or make changes to this bug.