tlug: HTTP question

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "FB" == "Frank Bennett (フランクべネット )" <bennett@example.com> writes:

    FB> I need to sling text strings back and forth between browsers
    FB> and our Web server.  I've been using encoded CGI "?" strings
    FB> for this purpose.

This usage is deprecated, AFAIK.  See below.

    FB>   o Is this truncation behaviour common to all browsers?  (I'm
    FB> a bit irritated by this, to be honest; I can see why a
    FB> *server* might want to squash lines that appear to be too
    FB> long, but I can't think of any utility in having a client
    FB> preemptively impose such a restriction).

Um, avoiding a buffer overrun sounds pretty likely to me.  Another
possibility is there is some garbage in the kanji string that tickles
a bug in MSIE's escaping function (see the Note below).  From the HTML
4.0 spec:

     http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13

17.13 Form submission

The following sections explain how user agents submit form data to
form processing agents.

17.13.1 Form submission method

The method attribute of the FORM element specifies the HTTP method
used to send the form to the processing agent. This attribute may take
two values:

    get: With the HTTP "get" method, the form data set is appended to
    the URI specified by the action attribute (with a question-mark
    ("?") as separator) and this new URI is sent to the processing
    agent.

    post: With the HTTP "post" method, the form data set is included
    in the body of the form and sent to the processing agent. 

The "get" method should be used when the form is idempotent (i.e.,
causes no side-effects). Many database searches have no visible
side-effects and make ideal applications for the "get" method.

If the service associated with the processing of a form causes side
effects (for example, if the form modifies a database or subscription
to a service), the "post" method should be used.

  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.

    FB>   o If not, is there a browser out there in common use that is
    FB> entirely free of length limits of this kind?

Mozilla.  If it's not, you can make it so.

Of course I'm not serious; point is, how can you _know_ without
reading the source?  Not worth it.

    FB>   o If not, is there an alternative, incompetely traumatic
    FB> method for sending archive text of arbitrary length to our
    FB> server from browser clients out in the field?  (Methods that
    FB> require the user to configure their machine specially to cope
    FB> with our site are *not* acceptable).

This is exactly what "method=POST" is designed for.  MSIE and Netscape
have both implemented it since 1995 at least; I don't think you have
to worry about that.  It's trivial to implement on the browser side;
for the server's CGIs most scripting languages provide libraries for
parsing POSTed forms.  The Portable Etruscan Retributive Lycophage has
several, although if you use Python your newt is likely to get better
sooner.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Nomikai: December 17 (Fri), 19:00 Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: January, 2000
* Topic: "glibc - current status and future developments"
* Guest Speaker: Ulrich Drepper (Cygnus Solutions)
* Place: Oracle Japan HQ 12F Seminar Room (New Otani Garden Court)
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan