- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 May 2012 20:27:54 +0200
On 2012-05-02 19:26, Evan Jones wrote: > On May 2, 2012, at 7:43 , Julian Reschke wrote: >> If browser implementers want to try something new that will not affect the old code paths, supporting the encoding defined in RFC 5987 might be the right thing to do (yes, it's ugly, but it's unambiguous). > > It seems to me like that is a potential solution that could be evaluated. It would be nice to have both the HTTP response header and the POST form encoding be the same. However, a critical question is if the server software that parses the form headers would do the "right thing" if it sees both an ASCII fallback filename= and an escaped filename*= parameter in the Content-Disposition header. Without looking at any code, I suspect some will and some won't. I'm pretty sure everybody will ignore filename* for now. Which means servers need to upgrade, but at least it would be an upgrade that doesn't break any existing behavior. > My conclusion: I would be willing to help with bugs, testing, test cases, looking at server code, etc related to this issue. However, I believe someone who is experienced with the technology and politics of web standards to really champion any change because I don't fully understand the processes or the issues. If I don't hear anything in a few days, I'll try filing some additional bugs with Webkit, Firefox, and the HTML5 spec and otherwise give up. > ... Sounds like a plan. Best regards, Julian
Received on Wednesday, 2 May 2012 11:27:54 UTC