Subject: Working Group Last Call: draft-ietf-httpbis-content-disp-02

From: Mark Nottingham <[email-masked]>
Date: Sat, 2 Oct 2010 19:45:07 +1000

With my Chair hat on --

Julian has indicated to me that (with his editor hat on), he believes that this document is ready for Working Group Last Call:

  http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-02

This is a three-week Last Call; it will end on Sat 23 Oct 2010 10:00:00 UTC.

Please read the document carefully and raise any issues you find -- design or editorial -- on this mailing list. If you review it and don't find any issues, please tell us that too, as it's useful information. 

If you don't wish to make your feedback public, please send it to me directly.

[I've copied part of Jeff Hodges' excellent WGLC announcement from Jeff Hodges for HTTP-STATE below, as I couldn't say it better myself...]

WHAT IS A LAST CALL FOR?

The purpose of the Working Group Last Call (WGLC) is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for consideration as an RFC at Proposed Standard maturity level.

During the last call, any comments on the documents are collected and discussed on the [email-masked] mailing list.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible outcomes:

1) No changes are required and we request our ADs to put forward the document to the IESG for proposed standard status.

2) Minor changes agreed to on the list are required, and the document is revised. We then ask our ADs to put forward the revised document to the IESG for proposed standard status.

3) Major issues are raised and no consensus is reached on the list. In this case, we slink back and discuss things until consensus is reached, at which time another working group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the document is with the IESG. The IESG reads it and may approve the documents (with or without changes), or send the document back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward for a two-week IETF-wide Last Call, and after successful completion the document is published as an RFC at proposed standard maturity level.

If the second outcome happens, we go back and address the issues, putting the document forward again when we believe we're ready.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 09:16:16 -0700

This document appears to be insufficiently precise for user agents to
implement Content-Disposition.  In particular, it does not
disambiguate what filename a user agent should use if multiple
filename attributes are present.  The grammar will fail to parse a
large number of Content-Disposition headers user agents receive on the
public Internet, etc.  The document says:

[[
   Based on interoperability
   testing with existing User Agents, it fully defines a profile of the
   features defined in the Multipurpose Internet Mail Extensions (MIME)
   variant ([RFC2183]) of the header field
]]

We should either add enough detail to the document to allow for user
agent implementations or clarify that this document is intended to
apply only to servers.  For example, we could change the above
paragraph to the following:

[[
   Based on interoperability testing with existing User Agents, it
defines a profile
   for use by HTTP servers of the
   features defined in the Multipurpose Internet Mail Extensions (MIME)
   variant ([RFC2183]) of the header field
]]

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Oct 2010 20:24:23 +0200

On 02.10.2010 18:16, Adam Barth wrote:
> filename attributes are present....

Repeating a parameter makes the header instance invalid, this should be 
pointed out; I opened 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/244> to track this 
(and also added a test case at 
<http://greenbytes.de/tech/tc2231/#attwith2filenames>).

> ... The grammar will fail to parse a
> public Internet, etc....

That's not a problem. There are no specific requirements on handling 
malformed headers, just like with any other HTTP header field, unless it 
affects security.

> ...  The document says:
> ...

I don't understand the distinction between user agent and server here.

We are defining a response header field. The producer sets it, 
expressing additional instructions on how to handle the payload. The 
recipient can follow it or ignore it. For instance, a UA on a mobile 
phone without filesystem will likely ignore the "attachment" disposition.

For invalid header field instances, there aren't any specific 
requirements. Do you have any evidence these are required?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 02 Oct 2010 21:46:04 +0200

>public Internet, etc.  The document says:

The parameters are advisory only; the draft defines that `filename*`
gives better advice than `filename`; there is little need to specify
something beyond that. As for content that falls outside the profile
here, browsers don't really agree on much. For instance,

  Content-Disposition: inline; attachment; filename=example.txt

that's "inline" in Opera and Firefox, but "attachment" in IE6. Something
that actually occurs practise is unquoted spaces,

  Content-Disposition: attachment; filename=ex ample.txt

That's "ex" in Firefox, but "ex ample.txt" in Opera and IE6. Malformed

  Content-Disposition: attachment;filename="example.txt".txt

is rejected as malformed by IE6 which then makes up its own name, but
it ends up as "example.txt" in Firefox and Opera. If we take the in-
tersection of what works in all major browsers and what actually occurs
in practise where it is more than a slight inconvenience for the user
if the header is ignored alltogether, we won't end up with something
that's noticably different than what's in the draft.

>apply only to servers.

That would be missing the point. The point of a profile specification is
that if a sender sends out something that conforms to the profile, then
recepients will process it in a manner conforming to the specification.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Oct 2010 21:54:47 +0200

> that's noticably different than what's in the draft.

Exactly.

That being said: thanks for the additional test cases; I'll add those 
over the weekend.

> recepients will process it in a manner conforming to the specification.

Yes. We need only one valid way to do things.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 14:43:33 -0700

> Yes. We need only one valid way to do things.

Right, this document is useful to folks who would like to generate
this header.  It's a generative profile.  As such, its a profile for
servers.  I'm just asking that the document be upfront about that.

One the other hand, this document isn't very helpful to folks who
would like to consume these headers.  Consumers will likely need to
implement the full protocol, not just the well-behaved profile.  As
such, we're still missing a specification for what user agents should
do with these headers, which is one reason we have the
interoperability problems Bjoern points out.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 14:48:40 -0700

On Sat, Oct 2, 2010 at 11:24 AM, Julian Reschke <[email-masked]> wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/244> to track this (and
> also added a test case at

There seems to be a lot of things generated by the grammar that are
nonsensical.  Perhaps it would useful to explain which of those things
servers ought to actually generate.

> malformed headers, just like with any other HTTP header field, unless it

We disagree about whether that's a problem.  We do agree that those
requirements are not contained in this document.

> I don't understand the distinction between user agent and server here.

This document describes a profile for generating the
Content-Disposition header.  The server is the one who generates the
header.  Therefore, this document defines a profile for use by
servers.

> We are defining a response header field. The producer sets it, expressing
> additional instructions on how to handle the payload. The recipient can
> follow it or ignore it. For instance, a UA on a mobile phone without
> filesystem will likely ignore the "attachment" disposition.

Indeed.  However, this document does not contain the rules for
consuming the header in sufficient detail for me to implement a user
agent.  I need to look at another document for that information.
Sadly, that document doesn't yet exist.

> For invalid header field instances, there aren't any specific requirements.
> Do you have any evidence these are required?

Such information is required to achieve interoperable implementations
of the Content-Disposition header.  It's fine if you don't want to
include that information in this document.  The document should just
be clear about its scope.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 16:40:54 -0600

> servers.  I'm just asking that the document be upfront about that.

Is Last Call for this draft the appropriate venue to agitate for change
to the way RFCs are generally written?  What you're suggesting sounds
like wholesale change to HTTP, such that all descriptions of MIME
header syntax are based on byte-code-level parsing models to encompass
current non-HTTP-conformant usage of those headers within HTTP messages.
Should this change be made for all other specs browsers may implement
which re-use MIME, as well?

I don't see how C-D isn't allowing a sender to define processing intent
for user agents, or how a user agent couldn't determine processing
intent from an HTTP-conformant C-D header.  It seems much more
confusing to me to describe a conformant C-D header for HTTP in terms
of a parsing model encompassing every unspecified usage of C-D
encountered so far in the wild.  Why *can't* interoperability be based
on conformant syntax, instead of agreeing how to handle nonconformant
syntax?

> implement the full protocol, not just the well-behaved profile.
>

I understand the stakeholder concern, but I don't understand why the
solution is to define conformant syntax in terms of a parsing model
based on all possible mangling of the syntax ever seen.  What problem
does that solve?  Why can't that solution be implementation-specific
instead of standardizing how to parse unstandardized syntax, which is
not germane to any use case except for browsers?  I fail to see what
interoperability concern exists for anyone generating this header in a
conformant fashion, or why such concerns are in-scope to this draft.

>
> As such, we're still missing a specification for what user agents
> should do with these headers...
> 

I don't understand the problem with drawing a bright line between what
everybody agrees on as a standard, and declaring everything else as
unspecified behavior.  Why should the existence of nonconformant syntax
have any bearing on how to handle conformant syntax?  Why are we
holding up C-D for being written like every other RFC I've ever read?

-Eric

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 15:57:08 -0700

On Sat, Oct 2, 2010 at 3:40 PM, Eric J. Bowman <[email-masked]> wrote:
> to the way RFCs are generally written?

I'm not agitating for a change to how RFCs are generally written.  I'm
saying that this document defines a profile of an existing protocol
element.  The profile is useful to servers.  The profile is not useful
for user agents.  The document should be clear about it's scope.

> What you're suggesting sounds like wholesale change to HTTP,

That's not what I'm suggesting.  HTTP is not a profile of another protocol.

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 03 Oct 2010 01:16:16 +0200

>interoperability problems Bjoern points out.

The goal is that authors can successfully suggest file names for and
treatment of entities that users may wish to download. That requires
that "servers" and "consumers" agree on a protocol to accomplish that.
The draft defines such a protocol, allowing for interoperability be-
tween "servers" and "consumers". This is about making stuff work, not
about cleaning up the mess browser vendors have created by arbitrarily
extending the protocol because they are not familiar with the concept
of input validation. That the draft does not try to fuse half a dozen
of differently broken implementations into a novel format for the
header that has only a small chance of being adopted properly does not
mean the protocol specification is for servers only.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 16:21:29 -0700

> mean the protocol specification is for servers only.

Insulting an important constituency is unlikely to generate consensus
by win that constituency over to your point of view.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 17:23:49 -0600

> for user agents.  The document should be clear about it's scope.

Not answering my questions fails to convince me of your position.  Most
folks are perfectly capable of generating conformant syntax from this
spec.  User agents will already interpret conformant syntax correctly.
The fact that *some* user agents desire to engage in error prevention
by also interpreting nonconformant syntax which will only be generated
in a minority of cases, sounds like an extreme edge case, not enough to
warrant making an incredibly confusing change to the spec to state that
it "isn't useful for user agents" when in fact it will be, 99% of the
time.  You've failed to explain to me why browsers can't take a "must
ignore" approach to nonconformant syntax, let alone any rationale
behind standardizing an error-prevention parsing model instead of
leaving that up to implementations.

> That's not what I'm suggesting.  HTTP is not a profile of another

But its headers are; they're re-used from MIME just like C-D, so I
don't see how your concerns about parsing nonstandardized syntax don't
also apply to *all* HTTP headers regardless of where they're defined,
not to mention *all* other specs which re-use MIME.  You seem to be
claiming that ABNF isn't precise enough to spec out one header in one
protocol (because it fails to define parsing for nonconformant syntax),
which seems like a concern which applies to all headers across many
protocols.

-Eric

---

From: David Morris <[email-masked]>
Date: Sat, 2 Oct 2010 16:31:39 -0700 (PDT)

> for user agents.  The document should be clear about it's scope.

I'm really confused by your argument ... I have no problem writing a 
parser for input generated by a clear specification as to how the input
should be generated. That is a sufficient specification for both the
generator and consumer of the data.

I really despise people insisting that I decode a parser specification so
I can figure out how to write my parser.

It is not necessary to state that this specification is from the
perspective of the server. It is a response header. QED from the server.

If the server generates the header and value as specified, the recipient
can process it. If the clients insisted on properly formed data, the
servers would be fixed rather quickly. Interoperability is about doing it
right, not agreeing on the secret sauce for how to handle garbage.

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 3 Oct 2010 10:56:23 +1100

Adam,

You raise one issue; are there others that justify adding this kind of statement to the specification? Could you give more examples?

Regards,

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 18:11:19 -0600

Adam Barth wrote:
> 
> Given that browsers are going to interpret nonconformant syntax, I'd
> rather live in a world in which they all did it the same way.  That
> world is more predictable, which is better for security, and easier
> for new entrants to the market because those new entrants don't need
> to reverse engineer existing implementations.  Fewer barriers to entry
> means more competition, which means users get a better browser
> product.
> 

The position is well-known, but that is not to say the premise is
agreed to by the majority, or any constituency beyond browser vendors.
I disagree entirely with the notion that it's somehow better for
security to change the must-ignore nature of Web architecture to one of
must-process...

http://blogs.wsj.com/digits/2010/09/24/what-caused-facebooks-worst-outage-in-four-years/

...given that this sort of error-prevention-correction approach leads to
just such a cascading database failure requiring the entire site to be
taken offline and brought back up in a different configuration, instead
of simply allowing 500 errors to occur.  That's the only way submitted
code will ever be corrected without opening a big gaping security/
stability hole by resorting to error correction.  I don't believe in
specifying any sort of error correction, because those hidden security/
stability implications are always lurking and aren't outweighed by the
need for user convenience.

If the spec were to define how to parse a string with two filenames,
it would lead to folks thinking it's conformant to send a string with
two filenames.  Or to transcode the string to have only one filename.
The last thing that the resulting confusion needs, is standardization.
The only thing which requires standardization, is how to do it properly.

> by win that constituency over to your point of view.

Speaking as a long-time Web Developer, I'm appalled by the dismissive
and insulting attitude taken by the constituency dictating HTML 5 as
pertains to the standards that myself and those like me are perfectly
capable of understanding, by declaring repeatedly that we're a bunch of
morons who can't understand resource/representation or anything else
the vendors are hell-bent on changing, as justification for said
changes ignoring those well-understood standards.

Which motivates me to participate in this thread, because I don't want
that vendor-centric approach to pollute HTTPbis, rendering the spec so
large and unwieldy that only browser vendors could ever hope to
understand its meaning, in terms of what they've implemented.  A big,
emphatic -1 to the notion that HTTPbis should follow HTML 5 down the
road of standardizing error correction behavior for user agents, for
C-D or anything else.

You have your rationales like "more secure," etc. but I have never
bought into the arguments behind them, as they defy my experience, most
recently confirmed by Facebook the day before yesterday -- error
correction is an inherent security problem and has no business being
written into HTTP.

-Eric

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 16:42:05 -0700

On Sat, Oct 2, 2010 at 4:23 PM, Eric J. Bowman <[email-masked]> wrote:
> time.

That's not the change I asked for.

> You've failed to explain to me why browsers can't take a "must
> ignore" approach to nonconformant syntax,

In general, browsers cannot take a "must ignore" approach to
nonconformant syntax for two reasons:

1) Nonconformant syntax is quite prevalent on the Internet.
2) Users have a choice of browsers and choose browsers that work with
their favorite web sites.

Because of (1), ignoring nonconformant syntax will cause a number of
web sites to break.  Because of (2), these broken web sites will drive
customers away, resulting in the browser that adopted this policy
losing marketshare.  For this reason, we observe that popular browsers
are the ones that interpret nonconformant syntax.

... but this is all well-known stuff.

> let alone any rationale

... but, again, this is all well-known stuff.

> which seems like a concern which applies to all headers across many

We can talk about what HTTP should do another day.  Today we are
talking about the Content-Disposition header.

> generator and consumer of the data.

I agree that it's sufficient for the generator, but don't you think
that it's extremely unlikely that the optimal profile of the
Content-Disposition header for generation is exactly the same as the
optimal profile of the Content-Disposition header for consumption?
I'm willing to believe this document contains the former.  I don't
believe it contains the latter.  I would prefer if the document where
upfront about what it contains.

> I can figure out how to write my parser.

No one is making that insistence.

> perspective of the server. It is a response header. QED from the server.

Unfortunately, servers don't just spam this header off into the void.
Someone wants to consume them!

> right, not agreeing on the secret sauce for how to handle garbage.

Are you suggesting that all user agents should implement exactly this
profile of the Content-Disposition header?  I neither believe that is
in their best interest nor do I believe they will do that, which is
why the document should be clear that it's not requiring them to do
so.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 17:23:44 -0700

If you'd like some (BSD licensed) examples of that a recent browser
implementation of the Content-Disposition header thinks are important,
you can look at the the test cases here (scroll down to
"content-disposition"):

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util_unittest.cc?revision=60555&view=markup

Here are some examples of things that look to be important but don't
seem to be covered in the document:

1) It looks like the disposition-type is actually optional, even
though it's required by the grammar.  It seems entirely possible that
the optimal generative grammar is to require the disposition-type
whereas the optimal consumption grammar is to default to some
particular disposition-type if none is provided.

2) It looks like the user agent is supposed to URL-decode the filename:

Content-Disposition: inline; filename="abc%20de.pdf"
=> abc de.pdf

Appendix C.4 seems to indicate that that this is implemented by IE and
Chrome.  From the comments in the file referenced above, it seems this
is important for the Asian market.  Both according to Appendix C.2 and
the comments in the file referenced above, it looks like the encoding
for the unescaped is supposed to be based on the current code page,
which admitted sucks.

Again, the optimal generative grammar is probably to avoid this mess.
However, it seems entirely likely the optimal consumption grammar is
to do something with percent-encoded inputs, especially if you care
about pleasing customers in the Asian market.

3) Apparently whitespace in the filename are supposed to be converted to spaces:

Content-Disposition: inline; filename="abc  <TAB><NEWLINE>de.pdf"
=> abc    de.pdf

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 17:26:06 -0700

As far as I can tell, your entire message is beating up on a strawman.
 I haven't proposed any of the things you're shooting down.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 18:44:10 -0600

>  I haven't proposed any of the things you're shooting down.

I'm shooting down the notion of standardizing nonconformant syntax,
which isn't a strawman if it's exactly what you proposed:

>
> >>
> >> Given that browsers are going to interpret nonconformant syntax,
> >> I'd rather live in a world in which they all did it the same way.
> >>  That world is more predictable, which is better for security, and
> >> easier for new entrants to the market because those new entrants
> >> don't need to reverse engineer existing implementations.  Fewer
> >> barriers to entry means more competition, which means users get a
> >> better browser product.
> >>
>

Because your rationales are strawmen -- you can't prove a negative,
i.e. state that any interpretation of nonconformant syntax is more
secure than ignoring it; or that in order to be competitive, browsers
must interpret nonconformant syntax.  It seems to me that it would be a
lower barrier of entry to only interpret conformant syntax, and that
the reduced complexity would result in a better product.  That's just
dueling opinions, you have failed to provide a technical argument in
support of standardizing how nonconformant syntax is to be parsed.

-Eric

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 03 Oct 2010 02:59:47 +0200

>by win that constituency over to your point of view.

There is a popular german short story by Peter Bichsel, "Ein Tisch ist
ein Tisch" (a desk is a desk). He tells of an old man who is trapped in
his daily routine, everything the same all day. One day he takes a walk
and for no particular reason he realizes he likes many thing about it.
He thinks that now everything will change, but when he comes home there
is still the same desk and still the chairs, the same bed, and he hates
it.

"Always the same desk", he says, "always the same chairs." And he starts
wondering why a desk is called "desk" and the chairs called "chairs". He
wonders why the bed isn't called "ball" and is amused by the thought.
"Now everything is going to change!", and from now on he calls the bed
"ball". "I am tired and want to go to ball."

Next day he ponders what to call the other things in his room; his desk
becomes "carpet", his chair "clock", his clock "photo album" and so on.
So in the morning he lays in his ball and around nine the photo album
rings. He is greatly amused and continues renaming things and replaces
the verbs also. He now had a language all for himself.

Eventually he started having trouble translating between his language
and the language the people around him use, to a point where he became
afraid to talk to them and started laughing when he heard others talk.
He stopped talking.

Meaningful communication requires that sender and recipient agree on the
meaning of what is being exchanged, otherwise they will fail to communi-
cate. Saying that the specification of a communication protocol is only
for "servers" is the equivalent of the old man telling you what words he
is using, but not telling you how you are to understand them. Since the
old man and you are using the same words, you would learn nothing from
that. A specification only for servers would at best make any sense at
all if there already was a higher-level specification that actually de-
fines the protocol, and the other specification is just a subset. This
is not the case here. This specification defines "If you send this, you
can expected it to be understood in this way"; "If you receive this, you
should understand it in this way." It addresses senders and receivers
alike. The idea that a communication protocol specification is only for
"servers" is silly.

What you rather want the specification to say is that there is a con-
siderable amount of content that does work in major implementation in
a specific way, but whose meaning is not defined by the specification,
and that that is a severe problem implementers will be interested in
addressing and be reasonably able to do so. So far you have provided
no evidence of that being the case, and my rudimentary tests suggest
you are mistaken.

If you can come up with something that works in all of IE6, Firefox,
and an independent third browser of your choosing, and demonstrate this
issue comes up for let's say 1 in 10,000 downloads with a content-
disposition header, where falling back to heuristics for the filename
would have substantial impact on the user experience, then I'd be more
than happy to talk about that. In my data I see only unquoted spaces
that do not work across major browsers, and headers that specify only
the filename (most of which are no problem because the filename they
specify is redundant with the typical heuristics) that occur at a
frequency worth mentioning. You are also more than welcome to propose
alternate metrics alongside your evidence. Vague suggestions that the
specification is inadequate are not helpful.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 19:01:54 -0600

Adam Barth wrote:
> though it's required by the grammar.
>

There's nothing wrong with C-D for HTTP having stricter requirements
than general-purpose MIME C-D.  Over time, browsers would no longer
need to support servers which don't send it.  I'd support changing the
draft language to deprecate treating it as optional.

> is important for the Asian market.
>

While that may be a valid stakeholder concern, what about all the times
I've used wget to dump a website from a Windows server to a UNIX server?
In which case I specifically don't want the spec instructing the user
agent whether or not to decode; it could be a CLI option.  User agent !=
browser, browser market concerns aren't always relevant to how HTTP is
used in reality.

-Eric

---

From: Adam Barth <[email-masked]>
Date: Sat, 2 Oct 2010 17:58:59 -0700

> which isn't a strawman if it's exactly what you proposed:

That's not what I proposed.  This what I proposed:

On Sat, Oct 2, 2010 at 9:16 AM, Adam Barth <[email-masked]> wrote:
> The document says:

In particular, the text above does not make the document appreciably
longer, but it does clarify that user agents are not required to
implement the restricted profile contained in this document.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 2 Oct 2010 19:15:20 -0600

Adam Barth wrote:
> >   features defined in the Multipurpose Internet Mail Extensions
> > (MIME) variant ([RFC2183]) of the header field
> > ]]
> 

That's clarifying a given, at the expense of making the entire document
unclear as to the point of a C-D header in the first place, which is to
declare the intended processing to user agents.  Not the expected
processing; I'd expect index.xhtml to be shortened to index.xht by any
user agent on a filesystem imposing a three-character extension limit.
The document is perfectly clear as written, there's no need to confuse
the issue by insisting it has nothing to do with user agent behavior
based on speculative edge-case concerns.

-Eric

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 11:29:07 +0200

On 02.10.2010 23:48, Adam Barth wrote:
> nonsensical.  ...

Such as?

> Sadly, that document doesn't yet exist.

You are claiming that it is insufficient to only accept valid headers. 
Please provide evidence, then we have something to discuss.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 16:01:48 +0200

> particular disposition-type if none is provided.

<http://greenbytes.de/tech/tc2231/#attmissingdisposition>

My tests show that the observable behavior is that the header is ignored 
(which is good).

> Content-Disposition: inline; filename="abc%20de.pdf"

Well, it's not supposed to from a standards point of view, nor from an 
interop point of view.

> for the unescaped is supposed to be based on the current code page,

It sucks totally, because it's impossible to be used in practice for an 
international audience.

The support in Chrome (which I complained about the day it came out, see 
<http://code.google.com/p/chromium/issues/detail?id=118>) might be 
well-intentioned, but will not always work as intended: long before 
Chrome and Safari where available, server implementers had to choose 
between the IE "encoding" and the RFC2231-encoding (supported by Firefox 
and Opera), and at least in some cases, the IE encoding would only be 
sent based on the User-Agent string (believe me, I had to write one of 
these). Remember -- until two years ago, only IE supported this broken 
encoding; thus Chrome made the situation worse by copying IE's broken 
behavior, instead of Firefox' and Opera's.

> about pleasing customers in the Asian market.

If you really care about pleasing Asian customers, please convince more 
UA implementers to support the standardized encoding, which does not 
depend on the client's locale, and also does not conflict with other 
legitimate uses of the filename parameter.

> Content-Disposition: inline; filename="abc<TAB><NEWLINE>de.pdf"
> =>  abc    de.pdf

I would consider this as part of post-processing something as filename, 
not the actual parsing. There are more things to worry about (stripping 
path separators, making things relative, avoiding trailing and leading 
whitespace, assigning a sane extension, and so on).

This is covered at the end of Section 3.3 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-content-disp-02.html#rfc.section.3.3>), 
but I would be surprised if there wasn't more that should be mentioned.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 15:44:35 +0200

On 02.10.2010 21:46, Bjoern Hoehrmann wrote:
> that's "inline" in Opera and Firefox, but "attachment" in IE6...

<http://greenbytes.de/tech/tc2231/#attandinline>

(IE8 behaves as IE6, Chrome and Safari behave like Opera and Firefox).

> ... Something
> That's "ex" in Firefox, but "ex ample.txt" in Opera and IE6....

<http://greenbytes.de/tech/tc2231/#attwithasciifilenamenqws>

IE8, Safari and Chrome are like Opera/IE6.

> ... Malformed

<http://greenbytes.de/tech/tc2231/#attbrokenquotedfn>

> that's noticably different than what's in the draft.

Exactly. I don't see any interop for malformed headers right now. 
There's nothing to be standardized, and also, nothing that *needs* to be 
standardized.

I'm much more interested in achieving interoperability for *valid* 
header fields.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 11:05:35 -0700

>> There seems to be a lot of things generated by the grammar that are

On closer inspection, the repeated filename issue is the most important.

> Please provide evidence, then we have something to discuss.

Jungshik Shin says "There are a lot of web sites that do what's
expected by IE."
http://code.google.com/p/chromium/issues/detail?id=118#c1

Do you have evidence that, for example, the percent encoding is rarely
used?  In the absence of evidence, it's unlikely implementations will
remove support for the behavior.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 11:08:06 -0700

On Sun, Oct 3, 2010 at 6:44 AM, Julian Reschke <[email-masked]> wrote:
> Exactly. I don't see any interop for malformed headers right now. There's
> nothing to be standardized, and also, nothing that *needs* to be
> standardized.

That's true from the server's perspective.  Servers are interested in
generating headers that work in the intersection of user agent
behavior.  User agents, however, are interested in processing the
maximal subset of Content-Disposition headers generated by servers.

> I'm much more interested in achieving interoperability for *valid* header
> fields.

Well, that depends on the definition of valid, doesn't it?

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 20:45:43 +0200

On 03.10.2010 20:08, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 6:44 AM, Julian Reschke<[email-masked]>  wrote:

OK, so I think the interesting question is: is the subset where there 
*is* interop today any bigger than the one defined in the spec?

> Well, that depends on the definition of valid, doesn't it?

Of course the definition of "valid" *could* be changed. Optimally, we'd 
stay consistent with general parameter parsing rules and previous specs, 
though.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 11:15:54 -0700

> Well, it's not supposed to from a standards point of view, nor from an

Well, we're writing the standards, so we can make them say whatever we want.

> It sucks totally, because it's impossible to be used in practice for an

Yes.  I agree that servers shouldn't generate %-encoded
Content-Disposition headers.  However, that doesn't mean it isn't in
the user agent's best interested to consume them if the user agent
receives one.

> well-intentioned, but will not always work as intended:

I would have responded on that bug exactly the way Jungshik Shin did.
WONTFIX.  That's the incentives user agent implementors face.

> long before Chrome
> and Safari where available, server implementers had to choose between the IE
> "encoding" and the RFC2231-encoding (supported by Firefox and Opera), and at
> least in some cases, the IE encoding would only be sent based on the
> User-Agent string (believe me, I had to write one of these).

Yes.  It's not a useful feature for server operators.  However, there
appear to be a number of servers in the Asian market that emit these
headers.  If a browser wishes to be used by folks in the Asian market,
the browser is incentivized to support this behavior.

> Remember --
> until two years ago, only IE supported this broken encoding; thus Chrome
> made the situation worse by copying IE's broken behavior, instead of
> Firefox' and Opera's.

That's a value judgment.

> If you really care about pleasing Asian customers, please convince more UA
> implementers to support the standardized encoding, which does not depend on
> the client's locale, and also does not conflict with other legitimate uses
> of the filename parameter.

I have nothing against supporting filename*.  What I object to is
having the spec ban a behavior that user agent implementors are going
to keep.

> I would consider this as part of post-processing something as filename, not
> the actual parsing. There are more things to worry about (stripping path
> separators, making things relative, avoiding trailing and leading

That's fine, as far as it goes.  A more informative spec would explain
exactly what transformations user agents should or should not do.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sun, 3 Oct 2010 12:48:41 -0600

> http://code.google.com/p/chromium/issues/detail?id=118#c1

I do not see the relevance of user agent implementation concerns, to
HTTP defining what constitutes conformant messaging syntax.  Provided
I'm sending conformant syntax, any user agent will understand what I
intend.  How can HTTP specify the filename must be decoded, when that's
dependent on the filesystem allowing the decoded characters?  It is not
required that HTTP be over-specified to account for every edge-case of
nonconformant syntax.

> remove support for the behavior.

Provided a user agent understands my conformant syntax, that user agent
is conformant with HTTP.  If that user agent also interprets non-
conformant syntax, that doesn't mean the user agent doesn't conform to
HTTP.  I don't see any requirement being imposed on browsers by this
draft, to remove support for whatever behavior they require or desire.

It is not required for the draft author to present evidence that the
percent encoding is rarely used.  That entire line of logic simply does
not apply to HTTP.  Think about my previous example of wget, widely
re-used by package management systems like ports/pkgsrc, and explain to
me why HTTP should dictate its behavior based on the market concerns
of browser vendors.

I have no less than four httpds running at this moment in my office,
embedded in my router and my printer, for example.  I will grant that
they generate crappy, nonconformant HTML.  I understand browser
vendors' concerns with defining a parsing model which understands HTML
as used in the wild, which is why I haven't pushed back on how HTML 5
is being authored.  But that logic simply does not apply to messaging.

HTTP is *not* a standardization effort around implementation details
within a component, its scope is limited to defining conformant
messaging syntax between connectors.  No evidence has been presented
explaining why HTTP should be a browser-behavior-centric specification
like HTML, and until that rationale is provided there is no basis for
demanding that the spec author present evidence that every edge-case of
nonconformant syntax has been accounted for, backed up by irrelevant
references to what browsers do.

-Eric

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 20:43:39 +0200

On 03.10.2010 20:05, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 2:29 AM, Julian Reschke<[email-masked]>  wrote:

OK, that will get a clarification as being invalid.

> remove support for the behavior.

The only reason why legacy servers would use percent-escaping is because 
they were written for IE only.

Every other server will sniff; and at least for the one case where I had 
to do this, I enabled the IE behavior only for IE. (Every other UA will 
get RFC2231 encoding).

I can't provide empirical data, though.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 11:50:40 -0700

> they were written for IE only.

So?  What incentive to user agents have to drop support for
%-encoding?  More tactilely, my reasoning is as follows:

1) Internet Explorer is not going to drop support for %-encoding.
2) Servers written for IE are not going away anytime soon.
3) Some user agents wish to compete in markets that contain these servers.
4) Those user agent aren't going to drop support for %-encoding.
5) The spec shouldn't forbid something that user agents are going to do anyway.

> Every other server will sniff; and at least for the one case where I had to
> do this, I enabled the IE behavior only for IE. (Every other UA will get
> RFC2231 encoding).

Does that mean your site doesn't work in Chrome?  More pointedly, does
your site provide Chrome an incentive to change its behavior?

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 20:53:27 +0200

On 03.10.2010 20:15, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 7:01 AM, Julian Reschke<[email-masked]>  wrote:

But we won't make it say that (as it breaks existing implementations) 
unless we have to.

Do we have to, despite we see that 4 out of 6 UAs tested do *not* do this?

> the user agent's best interested to consume them if the user agent

Again, 4 out of 6 browser implementations do not do this. So I simply do 
not buy the "but we have to" argument.

> having the spec ban a behavior that user agent implementors are going

Changing the spec to allow percent to be an escape character would break 
other existing implementations.

We can *warn* producers from relying on it, but the alternative (using 
the RFC 5987 encoding) will only work when IE/Chrome/Safari adopt it.

> exactly what transformations user agents should or should not do.

There's nothing exact to standardize right now, and it also depends on 
the limitations of the OS the UA runs on. From that point of view, 
requiring something specific seems to be the wrong approach.

That being said: if you have more potential things to consider in that 
part, please report them. I'm pretty sure there could be more than those 
I mentioned.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 20:59:39 +0200

> me why HTTP should dictate its behavior based on the market concerns

Eric,

this issue is indeed about *valid* messages.

See, for instance

   <http://greenbytes.de/tech/tc2231/#attwithfnrawpctenca>:

   Content-Disposition: attachment; filename="foo-%41.html"

According to all relevant IETF specs, this specifies a filename of 
"foo-%41.html".

IE and Chrome decode that as "foo-A.html". This breaks the 
interpretation of valid messages, and is only implemented in IE and Chrome.

I'm fully aware that IE and Chrome are not going to stop doing this 
anytime soon. The best way to workaround this issue is to require that 
clients support the RFC 5987 encoding, which would allow to 
unambiguously encode the name. Unfortunately, we aren't there yet.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 12:03:01 -0700

On Sun, Oct 3, 2010 at 11:45 AM, Julian Reschke <[email-masked]> wrote:
> OK, so I think the interesting question is: is the subset where there *is*
> interop today any bigger than the one defined in the spec?

That's the interesting question for folks who wish to generate the
header.  The question for folks who want to consume the header is
different.  The operative question is "what single semantic theory
captures the intended semantics of the largest number of messages
generated in practice?"  These two things are quite likely to be
different in this case.  (I'm writing up a longer message explaining
this statement.)

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 21:03:40 +0200

On 03.10.2010 20:50, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 11:43 AM, Julian Reschke<[email-masked]>  wrote:

On the other hand, the spec should define unambiguously what a valid 
message means, so we couldn't have two interpretations.

> your site provide Chrome an incentive to change its behavior?

The site I worked on (an SAP content management system) indeed will not 
work with Chrome, unless it has been fixed since Chrome came out (which 
I doubt because that system is in "maintenance mode"). It will send the 
RFC2231-encoded parameter, and Chrome will not "get" the "filename*" 
parameter. If RFC 2231 support was added in Chrome, the problem would 
simply go away with no server change being required.

Best regards, Julian

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sun, 3 Oct 2010 13:28:02 -0600

> different in this case.  (I'm writing up a longer message explaining

I understand what you mean perfectly well.  I still don't see the
relevance of that dichotomy to HTTP.  Why should C-D generation be
defined in terms of handling syntax that was never specified?  Why
should such implementation details even be included in HTTP?  Why
*isn't* 99% interoperability of the conformant syntax good enough?

> > HTTP defining what constitutes conformant messaging syntax.
> 
> Indeed.  It's precisely this lack of caring about the concerns of user
> agent implementors that's causing the problem.
> 

Browser vendors.  If addressing your concerns means that all user
agents are expected to behave like browsers, then my perspective is
that it would reflect a lack of caring about the concerns of anyone
else implementing HTTP.  What's right for browsers isn't necessarily
right for wget/curl, in fact the diverse re-use of those two user
agents is evidence that it would be impossible to come to consensus on
HTTP if its scope were to include implementation instructions for user
agents.  Some things are best left unspecified, rather than impossibly
overspecified.

-Eric

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 11:52:32 -0700

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 13:01:54 -0700

On Sun, Oct 3, 2010 at 12:28 PM, Eric J. Bowman <[email-masked]> wrote:
> defined in terms of handling syntax that was never specified?

No one is proposing that.

>  Why should such implementation details even be included in HTTP?

No one is proposing that.

>  Why *isn't* 99% interoperability of the conformant syntax good enough?

In general, browsers aim for somewhere between 99.99% and 99.999%
compatibility.  There are two ways to think about what 99%
compatibility would be like:

1) The browser does the wrong thing on 1% of all page views.  That
means users will be seeing the browser do wrong things on a daily, or
at least weekly, basis (based on statistics about the distribution of
number of page views).  That more than enough to drive potential
customers away.

2) The browser does the wrong thing on 1% of all web sites.  Which of
the Alex top 100 web sites would you like your browser to be
incompatible with?  Let's try the 100th ranked one: NewEgg.com.  If I
checked in a change that broke compatibility with NewEgg, I'm pretty
sure I'd have to fix it.

Even with all the effort that browsers put into compatibility, "not
compatible enough" is a top reason for user attrition according to
uninstall surveys.  This stuff really matters.

Why 99.99% to 99.999%?  Well, now the user can use the browser for a
year without seeing compatibility problems and I've broken
effectivesafelist.com.  Now, I'm sure effectivesafelist.com has an
audience that will be sad about that, but I can't please everyone.

> agents.  Some things are best left unspecified, rather than impossibly

That's all fine.  What I'm asking for is that the Content-Disposition
spec not forbid browsers from doing things they're going to do anyway.

Adam

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sun, 3 Oct 2010 14:43:23 -0600

> No one is proposing that.

Well, yes, you're suggesting that the conformant syntax include %-
encoding, which was never defined as allowable syntax to begin with.
It isn't an error in the C-D draft to exclude syntax that's never been
specified, by defining a subset of syntax that has been specified,
which treats % as a literal character.

> No one is proposing that.

I'm still responding to you original claim, "This document appears to
be insufficiently precise for user agents to implement Content-
Disposition...  The grammar will fail to parse a large number of
Content-Disposition headers user agents receive on the public Internet,
etc..."  The only thing you've said is that in lieu of such details,
the draft should include language stating that it isn't useful to user
agents.  I'm against both.

> number of page views).  That more than enough to drive potential

That's where you and I are going to have serious disagreements on the
nature of _networked_ software architecture.  The Web isn't a closed
system.  Errors need to be reported to users, or rather, developers.
Once the producer of content sees an error instead of a result, the
error may be fixed.  Your perspective is what leads to total site
failure to avoid reporting a 500 error to the user, i.e. Facebook
DDoS'ing itself the other day.  That's "correct" behavior?  I'd rather
my website visitors see error messages (or rather, that I see them and
correct them first) than break how the Web achieves interoperability at
Internet scale (by allowing errors to happen, primarily 404).

The concern about driving customers away is an *opinion* and not a fact,
and even if true, the consequences of silent recovery in browsers lead
to the much larger problem of gaping security/stability holes.  Willful
violations of Web architecture can't be called secure in the name of
user convenience, nor are errors resulting from not following standards
to be considered "bad behavior" or the "wrong thing" -- they're critical
to the nature of _networked_ software architecture on the open Internet.
Browser vendors' desire to hide errors leads to a more fragile Web, i.e.
the opposite of the robustness principle.

You can't tell me that you've thought of and accounted for every
possible consequence of abandoning standard MIME syntax for C-D in
favor of allowing %-encoding.  Whereas I'm quite comfortable with the
notion that any interoperability issues with conformant syntax lurking
out there would've been found by now.  It defies logic to claim that
it's easier for a new entrant to the browser market to implement
different parsers for different headers instead of following MIME
syntax defined for *all* headers.

-Eric

---

From: Adam Barth <[email-masked]>
Date: Sun, 3 Oct 2010 13:56:09 -0700

> the opposite of the robustness principle.

People have been making that argument for years, and still the popular
user agent implementor follow their incentives to maximize
compatibility.  Presumably the ones that listened to this advice
failed to become popular.  You're not going to change their behavior
without changing the incentives.

> syntax defined for *all* headers.

... and yet that's exactly what the newest successful entrant into the
market has done.  I encourage you to bring a browser to market that
behaves as you suggest.  I suspect you'll have great difficulty
acquiring users if the folks who try your browser experience an
incompatible web site every day or if they can't use NewEgg.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 21:10:37 +0200

On 03.10.2010 20:52, Adam Barth wrote:
> On Sun, Oct 3, 2010 at 11:48 AM, Eric J. Bowman<[email-masked]>  wrote:
>> Adam Barth wrote:

I don't think finger pointing is helpful.

If I wasn't interested in user agent concerns, I wouldn't have compiled 
all the test cases and results, opened bugs, communicated with browser 
vendors, and even fixed some of the bugs in Firefox.

The main issue that we have is that Microsoft for some reason invented a 
new syntax instead of using the proposed one, then did not document it, 
and also did not make it work in all cases (making it dependent on the 
recipient's local). It simply was a very very bad design decision. And 
that Chrome copied it (despite the fact that no other browser did) 
didn't help.

Best regards, Julian

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sun, 3 Oct 2010 15:11:34 -0600

Adam Barth wrote:
>
> > The concern about driving customers away is an *opinion* and not a
> > fact, and even if true, the consequences of silent recovery in
> > browsers lead to the much larger problem of gaping
> > security/stability holes.  Willful violations of Web architecture
> > can't be called secure in the name of user convenience, nor are
> > errors resulting from not following standards to be considered "bad
> > behavior" or the "wrong thing" -- they're critical to the nature of
> > _networked_ software architecture on the open Internet. Browser
> > vendors' desire to hide errors leads to a more fragile Web, i.e.

Just as you're not going to change how RFCs are drafted by calling the
result "correct architecture" that needs to be specified by HTTP.  The
concerns of browser vendors aren't the only concerns around HTTP, which
can't fundamentally oppose the nature of _networked_ software
architecture based on the *assumption* that the result will be an
improved Web -- when you haven't offered any proof that it wouldn't
cause the whole thing to come crashing down into a smoking non-
interoperable heap by allowing all unspecified syntax instead of
restricting to what's defined by MIME.

> > favor of allowing %-encoding.  Whereas I'm quite comfortable with
> > the notion that any interoperability issues with conformant syntax
> > lurking out there would've been found by now.  It defies logic to
> > claim that it's easier for a new entrant to the browser market to
> > implement different parsers for different headers instead of
> > following MIME syntax defined for *all* headers.
> 
> market has done.

Hardly a convincing rebuttal to my point that having separate parsers
for separate headers raises the bar on any new entrant to the market --
"Yes, they do, but this didn't stop Google."  I forgot how limited are
Google's resources...

>
> I encourage you to bring a browser to market that behaves as you
> suggest.  I suspect you'll have great difficulty acquiring users if
> the folks who try your browser experience an incompatible web site
> every day or if they can't use NewEgg.
> 

I have no desire to enter the browser market, which doesn't mean I
don't develop HTTP user agents for other purposes.  I don't care how
such user agents interpret NewEgg, I only care how they interoperate
with the standards as written, and I certainly care that they don't
engage in silent error correction when encountering nonstandardized
syntax because "so does Google and Microsoft."

It's ludicrous to suggest that I write separate parsers for separate
headers because HTTP standardized syntax I never would have suspected
to be valid based on 17 years of experience.  If Google, Apple and
Microsoft want to increase time-to-market and complexity to solve
problems I'll never face, fine by me, but don't impose their solutions
back on the rest of the world by standardizing aberrant behavior.

-Eric

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Oct 2010 18:12:34 +0200

> I can't provide empirical data, though.

...but I *can* provide a link to a thread where the same solution was 
mentioned:

"...The solution at the end was to detect IE via the user agent header, 
do IE's way for the filename and do the RFC 2231 way for others. But,
that's assumes UTF-8 URL encoding is turned on in IE..." -- 
<http://lists.w3.org/Archives/Public/public-html/2008Mar/0119.html>

Best regards, Julian

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Mon, 04 Oct 2010 11:47:55 -0500

On 10/4/2010 11:12 AM, Julian Reschke wrote:
> ...but I *can* provide a link to a thread where the same solution was mentioned:
> 
> "...The solution at the end was to detect IE via the user agent header, do IE's way for
> the filename and do the RFC 2231 way for others. But,

In lieu of handling %-escapes, which were 1) semantically nonsensical in http
response headers (while 2231 would be valid) yet 2) not fully nonconforming,
since they were 7 bit ascii clean, so they did not trip up 7 bit handling...

Why not simply drop filename= as a legacy, nonstandard representation, similar
to the original cookie spec, and replace with name= or similar for all RFC2231
conforming names?

This would allow both user agents and servers to continue to interoperate with
legacy schemas, while offering a bridge to HTTP/1.1 semantics.  The definition
of a name= argument could reasonably be declared to override any filename=
argument observed.

Possibility?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Oct 2010 19:13:02 +0200

> of a name= argument could reasonably be declared to override any filename=

"name" would be something new. "filename*" has been a proposed standard 
for ages, and has three independent implementations, and is used in 
practice.

As far as I can tell, the deployment story for "filename*" is the same 
as for "filename", as soon as Opera and FF correct their parsing when 
both "filename" and "filename*" are present.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Oct 2010 15:49:23 +0200

> both "filename" and "filename*" are present.

This is fixed in the Release Candidate of Opera 10.63.

What's left to-do is to get the fix for 
<https://bugzilla.mozilla.org/show_bug.cgi?id=588781> into Firefox 4.

Best regards, Julian