RE: direct input limit?

On Wed, 24 Aug 2005, Yves Lafon wrote:

> On Wed, 24 Aug 2005, Paul Cooper wrote:
>> 
>> Ah, yes. Thanks guys. That'll be the problem.
>> Strange they chose GET and not POST. Forgot the limit for GET was so low.
>
> There is no limitation per RFC2616, just a de-facto limitation because of the 
> bugs in some browsers

That is correct. The same applies to many limitations that we need to 
observe in order to make things work on the WWW as of today and tomorrow.

> (that may be replaced by newer versions without this 
> bug in the future).

Certainly. And Bovine Aviation Enterprises might make a breakthrough.
(Moo moo flap flap.)

> So I am not keen on misusing the HTTP verbs only to do a bug workaround.

Even if that's the only way to make this function of the service 
operational on the most widely used browser?

Besides, the HTTP "verbs" GET and POST are a real mess from the beginning.
(Some details: http://www.cs.tut.fi/~jkorpela/forms/methods.html )

When there's no clear definition of correct use, what does "misuse" 
mean? From the beginning, the difference between the methods has been
partly logical (do you just fetch something, or do you change something?), 
partly technical (how do you pass the data?). There was never a clear 
definition of how these things relate to each other, but the general idea 
seems to be that technical problems trump logic here. In fact, the HTML 
4.01 specification (continuing the tradition) explicitly says that for 
GET, form data is limited to ASCII codes.

Thus, by the HTML specification, the text input is now limited to ASCII 
characters. If any other characters are entered in the text area, the 
effect is undefined.

I'd rather have POST there. If it helps, you could always add some 
server-side processing (like updating a counter) and call it
a side effect, notice that it is not idempotent, and feel right
about using POST. :-)

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Wednesday, 24 August 2005 20:36:45 UTC