On Thu, 3 May 2012, Evan Jones wrote:
On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
Yes. I think we should define multipart/form-data directly in HTML and
thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated
and not maintained.
Right; that would be ideal.
On 2012-07-09 23:01, Ian Hickson wrote:
On Thu, 3 May 2012, Evan Jones wrote:
On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
Yes. I think we should define multipart/form-data directly in HTML and
thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated
and not maintained.
On Mon, 9 Jul 2012, Julian Reschke wrote:
I agree with the methodology. However I would suggest to simply revise
RFC 2388.
The precise details of the process of how it's done are up to whoever
writes the spec text, they're not really relevant to this list.
--
Ian Hickson
On Fri, 04 May 2012 01:59:15 +0200, Evan Jones ev...@csail.mit.edu wrote:
I would be interested in trying to help with this, but again I would
certainly need some guidance from people who know more about the
vagaries of how the various browsers encode their form parameters /
uploaded file
On Tue, 01 May 2012 18:12:36 -0700, Evan Jones ev...@csail.mit.edu wrote:
… this seems contradictory: Encode using RFC 2388, but do not using the
encoding suggested by the RFC. Worse, no browser actually follows the
RFC (e.g. they all use UTF-8 encoded parameter values), so that doesn't
On May 3, 2012, at 17:09 , Anne van Kesteren wrote:
Yes. I think we should define multipart/form-data directly in HTML and
thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated and not
maintained.
Right; that would be ideal. Despite the fact that HTML5 references that RFC,
On May 1, 2012, at 22:38 , Ashley Sheridan wrote:
The Webkit method looks the better of the two with regards to how
server-side languages might interpret it, but it would need work to
ensure everything that should be escaped is, and that everything that is
unescaped on the server should be and
On 2012-05-02 13:05, Evan Jones wrote:
On May 1, 2012, at 22:38 , Ashley Sheridan wrote:
The Webkit method looks the better of the two with regards to how
server-side languages might interpret it, but it would need work to
ensure everything that should be escaped is, and that everything that is
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
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).
I am not an experienced web standards wonk, so please forgive me if I'm making
a mistake here.
When uploading files that contain special characters in their name, it appears
to me that it is unspecified as to how those file names should be escaped. As a
result, Webkit/Safari/Chrome appear to
On Tue, 2012-05-01 at 21:12 -0400, Evan Jones wrote:
I am not an experienced web standards wonk, so please forgive me if I'm
making a mistake here.
When uploading files that contain special characters in their name, it
appears to me that it is unspecified as to how those file names should
12 matches
Mail list logo
