Bug 62110 - Should set Accept header to object/@type when fetching remote object
Summary: Should set Accept header to object/@type when fetching remote object
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-05 10:34 PDT by Xavier Morel
Modified: 2011-06-05 23:52 PDT (History)
2 users (show)

See Also:


Attachments
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/x-python)
2011-06-05 10:34 PDT, Xavier Morel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xavier Morel 2011-06-05 10:34:13 PDT
Created attachment 96052 [details]
Short WSGIREF script testing the MIME type sent by the browser when fetching a remote resource linked from an object tag

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), Webkit 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.

Expected:
Webkit 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

Observed:
Webkit 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'

Testing:
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 Alexey Proskuryakov 2011-06-05 21:33:33 PDT
Does it work as you expect in IE or Firefox?

I do not see HTML5 say anything about the Accept header when fetching data for <object>.
Comment 2 Xavier Morel 2011-06-05 23:52:31 PDT
(In reply to comment #1)
> Does it work as you expect in IE or Firefox?

No, it does not work in any browser. I have opened a similar bug for Gecko.

> I do not see HTML5 say anything about the Accept header when fetching data for <object>.

It does not, as far as I know, but that would seem a pretty logical usage of @type considering it's supposed to be a valid MIME type, would it not?