- From: Adam Barth <ietf@adambarth.com>
- Date: Wed, 1 Dec 2010 13:13:54 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Dec 1, 2010 at 1:00 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 01.12.2010 20:50, Adam Barth wrote: >> On Wed, Dec 1, 2010 at 3:12 AM, Mark Nottingham<mnot@mnot.net> wrote: >>> Adam, do you have a proposal? >> >> Yeah. Please find my proposal below. It's certainly not beautiful, >> and it likely needs more polish, but it should be a starting point. >> ... > > before I look at the details, I'd like to understand the intent. Thanks for seeking to understand instead of jumping to conclusions. :) > You're saying this reflects roughly what Chrome is doing. Thanks for writing > this down. > > But exactly *why* would we consider this for the spec (I assume as > recommended error recovery?)? Oh, I thought we discussed this before. From my perspective, the current spec is optimized for server operators. In particular, it's helpful if you'd like to generate the Content-Disposition header. I raised the issue that user agent implementors might like information about how to consume the Content-Disposition header. We then had a long discussion about why the optimal generation instructions and consumption instructions might not be identical. I think, then, Mark suggested that we could include that information in an appendix that user agents could optionally implement, if they were so inclined. One important constraint is that the consumption requirements agree with the rest of the spec on well-formed headers (i.e., on those that meet the generation requirements). If it's helpful for you to think about this information as recommended error recovery, that's fine with me. When consuming the Content-Disposition header, it's not especially important to know whether the header is well-formed (i.e., generated in accordance to the generation requirements). > I note that you have handling of RFC2047-style encoding in there. That's > something only Chrome and Firefox are doing, so I'd like to understand why > you think it's needed, and whether you think Opera/Safari/Konqueror/IE > should implement that (given the fact that changes the semantics of values > that are valid). Yeah, I wasn't sure whether to include the RFC2047 encoding. I certainly wouldn't recommend that servers generate Content-Disposition headers using that encoding. However, if I were writing a new user agent today, I might well include RFC2047 support. It boils down to a cost/benefit analysis. Some comments in the Chrome code indicate that there are servers that do generate RFC2047-encoded Content-Disposition headers, so there's at least some benefit. One thing that might make sense is to demarcate those instructions as again optional, that is an optional piece of the optional error recovery, if you like. Adam
Received on Wednesday, 1 December 2010 21:15:00 UTC