This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 177 - Textarea should POST, not GET
Summary: Textarea should POST, not GET
Status: RESOLVED FIXED
Alias: None
Product: CSSValidator
Classification: Unclassified
Component: text area (show other bugs)
Version: CSS Validator
Hardware: Other other
: P2 major
Target Milestone: ---
Assignee: Olivier Thereaux
QA Contact: qa-dev tracking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-12 12:18 UTC by Bj
Modified: 2008-03-12 16:14 UTC (History)
2 users (show)

See Also:


Attachments

Description Bj 2003-03-12 12:18:18 UTC
The text area form uses GET for submission. This causes the form to fail on 
various browsers since they limit the length of URIs to a fixed value which 
style sheets often exceed.
Comment 1 Etan Wexler 2004-10-04 08:25:15 UTC
The beauty of the GET HTTP request method is that we can construct test cases
that are URIs. I refuse to abandon this utility.

Does using the POST method violate Web architecture or the HTTP 1.1
specification (<urn:ietf:rfc:2616>)? After all, testing for CSS validity of a
string is a safe operation. Time to slog through the Web-architecture
specification...

Both methods can be options of the validator service. How to arrange this dual
offering in a usable manner is yet another discussion, I think.
Comment 2 Jordan Moore 2005-08-16 22:19:07 UTC
You could use JavaScript to insert a set of radio buttons that sets the method
of the form (POST or GET), and then use a <noscript> element to display a link
to the POST version for non-JS users.

If you don't like <noscript>s, you could simply use the DOM to remove the
paragraph with the link to the POST version.
Comment 3 Jesse Skinner 2006-02-16 19:04:37 UTC
Why not allow the values to be sent with either GET or POST, and change the
front-end textarea to use POST? Then, the test cases will still work as URLs.

To construct the test case URLs, you could just save the form locally, change
the 'method' from POST to GET, and change the 'target' to point at the live server.
Comment 4 Olivier Thereaux 2007-07-20 05:15:35 UTC
An argument mentioned by Jukka on the mailing-list, in favor of POST:
[[
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
]] http://lists.w3.org/Archives/Public/www-validator-css/2007Jul/0020.html
Comment 5 Olivier Thereaux 2007-07-20 06:17:23 UTC
patched the validator to allow handling of direct input via POST.
http://dev.w3.org/cvsweb/2002/css-validator/org/w3c/css/servlet/CssValidator.java.diff?r1=1.31&r2=1.28&f=h

Yves, could you give it a glance?
(we need to install tagsoup and java 1.6 on qa-dev, our testing ground is non functional until we do).
Comment 6 Maxx 2007-12-14 10:28:10 UTC
Could the above fix be deployed in production?
Thanks.

I'm currently stuck with this CSS validator, because testing CSS files of an internal enterprise application (thus unavailable on the internet) and my stylesheets are a little bigger than the HTTP max URL length.
I have to send each of my CSS's through the file input to validate them one by one
instead of just copy/paste the content of them.
Comment 7 Olivier Thereaux 2007-12-28 03:18:17 UTC
(In reply to comment #6)
> Could the above fix be deployed in production?

We're waiting for translations to be completed before we can put the latest validator in production.
http://qa-dev.w3.org:8001/css-validator/translations.html
Comment 8 Olivier Thereaux 2008-03-12 16:14:21 UTC
in production now.