Re: Content Type

Hi Victor,

> 2 cents:
>
> Isn't it time for user agents to start reporting more fine grained which
> standards they support? 
Oh yeah it is time.

> The HTTP Accept header doesn't provide enough
> information to know whether a document will be understood at all, and
> can lead to quite a few hacks, specially on sites using cutting edge
> technology, such as SVG or AJAX.
>   
Well the problem is that the Accept header had not foreseen the overall  
XHTML modularity I guess. The Accept header lists media-types the UA 
says to support and even let the UA specify the level of preference they 
have for each media-type but as you say it is not flexible enough to 
work well with XML documents.
>
> What if browsers could negotiate support with the server using e.g.
> namespace URIs, where these would reference either a standard, part of
> it, or some pre-defined support level? Poof, SVG 1.1 Tiny 95% supported,
> CSS 3 10% supported, DOM level 2 80% supported, etc..
>   
This would not work because your percentage does not say what it covers. 
A browser can support 10% of XForms but it does not say exactly what it 
does support. It would work only if specification provided those levels.

Say levels A, B, C and D defined by a given specification, UA could say 
I support level A and we would know what that covers.
> Obviously, the Accept header would be much longer, but the contents
> received could be reduced significantly. Also, I believe it would be
> easier for developers to use only Accept header switching than learning
> all the hacks necessary for modern web development.
>   
Agreed.
> I don't really know if this is possible, but maybe this kind of Accept
> header could be separated into a special HTTP reply. This would contain
> the URIs of the potential contents, and the user agent would send a new
> HTTP GET request with the modified Accept header, reporting the support
> levels.
>   
I guess it should simply a new HTTP header.

- Sylvain

Received on Wednesday, 22 March 2006 10:32:27 UTC