[WebKit-devel] [Bug 261223] Download name of link targets containing special characters get ignored

[Dawit Alemayehu]

https://bugs.kde.org/show_bug.cgi?id=261223





--- Comment #12 from Dawit Alemayehu <adawit kde org>  2011-01-09 18:28:55 ---
(In reply to comment #11)
> >> So the server just sends garbage and the browser just ignores it.
> > The attribute value in question is no garbage but just missing the quotes
> > required by RfC 2216.
> 
> So it is invalid, which qualifies it as garbage.

I believe you are incorrect about this whole thing:

First, the "Content-Disposition" header is not an HTTP standard. It is simply a
derived one that relies on other standards for its definition as well as
security implications. See RFC 2616 section 15.5. As such the sections of RFC
2616 in comment #9 are not technically applicable to this header. You would be
better served by looking at RFCs 2183 and RFC 5987 if you have not already done
so. Specially RFC 5987, which is not only more recent than RFC 2616, but it
also has specific recommendations about the parameters in content-disposition,
see
section 3.2.1.

Second, there is actually a prefect reason why file names with LWSP should be
quoted. It avoids ambiguity for parsers that might rely on white spaces to
create tokens. However, there is no reason or justification for following that
for non-latin1 characters that are not
special characters like control and LWSP characters.

Third, and we currently violate the spec when the file name are quoted. There
is no check for illegal characters such as control characters when parsing
quoted file names.

Anyhow, to me even if that was not the case and we did everything right, but
all the other browsers implemented something differently, then the defacto
standard is the one that should be chosen. There is absolutely no way you can
adhere to RFCs 100% and get anything that is
usable in the real world. A little pragmatism is necessary when implementing
these standards. Believe I learned that the hard way as well after implementing
several RFCs including 2616 for which I had to write many workarounds for
brain-dead implementations...


> See http://greenbytes.de/tech/tc2231/#attwithasciifilenamenqws for basically
> the same example and how basically all browsers misbehave. 

Ahhh... that test is for a white space... How are white spaces and valid
non-latin1 characters the same ? And why should they be treated the same ?

> Note the green line of Konqueror. You could ask Julian if this shouldn't be a 
> expected fallback behaviour.

And the patch I propsed does not break that test, but fixes the problem
reported here.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.