W3C home > Mailing lists > Public > www-validator-css@w3.org > July 2007

Re: A bug's life

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Thu, 19 Jul 2007 13:31:08 +0300 (EEST)
To: www-validator-css@w3.org
cc: Jean-Guilhem Rouel <jean-gui@w3.org>
Message-ID: <Pine.SOC.4.64.0707191325150.16486@hopeatilhi.cs.tut.fi>

On Thu, 19 Jul 2007, olivier Thereaux wrote:

>> 177 -> not sure we want to use POST as it seems to be against the HTTP 1.1
>> spec
>
> In theory I agree. In pragmatic terms, though, it is indeed true that most 
> UAs have a hardcoded limit to the URIs they can GET, and that's a clear 
> usability issue for our users. As much as GET is useful for debug purposes, 
> I'd be OK with using POST for the direct input, as we already do for the 
> markup validator.

Using POST is not against HTTP 1.1, and POST is the right method to use, 
when the input may contain non-ASCII data. Actually, it might be argued 
that POST is _always_ the right method on the web (or even generally), 
since the input may always contain non-ASCII characters, even if they 
might be considered as bad data.

Quoting the HTML 4.01 spec:

"Note. The "get" method restricts form data set values to ASCII 
characters. Only the "post" method (with enctype="multipart/form-data") is 
specified to cover the entire [ISO10646] character set."
   http://www.w3.org/TR/html4/interact/forms.html#h-17.13.1

(In practice, browsers do funny things if you have non-ASCII characters in 
data submitted via the GET method, and if you know how they work, you 
might be able to process the data as intended by the sender, in almost all 
cases. But protocolwise, you're out of luck with GET if there's any 
non-ASCII data, and you cannot prevent users from entering non-ASCII 
data.)

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Thursday, 19 July 2007 10:31:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 June 2012 00:14:19 GMT