Re: UA support for Content-Disposition header (filename parameter)

On Mar 16, 2008, at 4:02 AM, Julian Reschke wrote:

>
> Maciej Stachowiak wrote:
>>> Lachlan Hunt wrote:
>>>> ...
>>>> It is not the job of the HTML5 specification to require that  
>>>> implementers support other specifications that do not have a  
>>>> direct impact upon the features in HTML5.  Please just file  
>>>> appropriate bug reports with browsers vendors that do not support  
>>>> the features defined in that RFC.
>>>> ...
>>>
>>> As a matter of fact, a bug report was raised against IE (something  
>>> like 2003), and the answer was that it's not a bug.
>>>
>>> That's why I think it would be a good thing if HTML5 clarified  
>>> that RFC2231 support is required.
>> Does the latest HTTP RFC require RFC2231? That sounds like the  
>> right place to start, if we are to consider this RFC mandatory for  
>> user agents.
>
> The latest HTTP RFC (2616) doesn't even require Content-Disposition;  
> it is described under "Additional Features" (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.19.5 
> >):
>
> "RFC 1945 and RFC 2068 document protocol elements used by some  
> existing HTTP implementations, but not consistently and correctly  
> across most HTTP/1.1 applications. Implementors are advised to be  
> aware of these features, but cannot rely upon their presence in, or  
> interoperability with, other HTTP/1.1 applications. Some of these  
> describe proposed experimental features, and some describe features  
> that experimental deployment found lacking that are now addressed in  
> the base HTTP/1.1 specification."
>
> Also note that RFC2231 describes more things as those needed for  
> I18N support of filenames. I'm not sure whether these parts are  
> implemented anywhere.

OK, it sounds like the HTTP working group is the place to start, then.  
Have you tried asking them?

> However, I'm sort of surprised to hear these kinds of arguments in  
> the context of this working group. What happened to "pave the cow  
> paths", "do not reinvent the wheel", "solve real problems", "support  
> world languages" and so on...?

I don't see how any of these are relevant to my suggestion (not  
argument) that making optional parts of the HTTP protocol mandatory is  
better done in the HTTP spec, if possible. More generally, problems in  
the areas of other working groups are better solved by those working  
groups, until they show they can't or won't. So if you fail to get  
traction on your proposal with the HTTP WG, then as far as I am  
concerned you are welcome to bring your proposal back here. Still, in  
my mind RFC2231 is indeed a solution, and if it is not getting  
deployed, then your beef is with implementors, not standards groups.

> RFC2231 (or a subset of it) solves the I18N problem for the filename  
> parameter, and it is implemented in (as far as I recall) Firefox and  
> Opera. I'm not aware of any other solution to that problem  (the one  
> used in IE depends on the client's config; thus can not be reliably  
> assumed to work).

I agree that it is a good approach which should become a cross-browser  
solution. On the other hand, RFC2231 does have problems, namely it  
does not provide good support for degrading gracefully in UAs that  
only support the plain Content-Disposition header, meaning in practice  
you have to UA sniff to use it at all.

> So why would this be out-of-scope for HTML5, while it (still)  
> includes crap like "Peer-to-peer connections over IrDA" (<http://www.w3.org/html/wg/html5/#irda-peer 
> >)?

Now I'm not sure if you are trying to solve a problem in good faith or  
making an ironic suggestion to prove some sort of philosophical point.

For what it's worth, I personally think "peer-to-peer connections over  
IrDA" and indeed all of "6.3 Network connections" should be dropped,  
and I would expect it will be dropped in due course due to lack of  
implementation support. It is arguably "in scope" in the technical  
sense, since our charter includes "Networking APIs for server-push,  
asynchronous two-way client-server communication, peer-to-peer  
communication, and client-side cross-domain communication" <http://www.w3.org/2007/03/HTML-WG-charter.html 
 >. But I think this section is immature and at least in the case of  
TCP connections poorly designed.

Still, I don't see what this has to do with your suggestion.

Regards,
Maciej

Received on Sunday, 16 March 2008 18:35:17 UTC