662169 - Should set Accept header to object/@type when fetching remote object

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Morel Xavier]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) 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.

Comment 1

[Morel Xavier]

Attachment: Short WSGIREF script testing the MIME type sent by the browser when fetching a remote resource linked from an object tag

Comment 2

[Boris Zbarsky [:bzbarsky]]

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!).

Comment 3

[Morel Xavier]

(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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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...

Comment 6

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.