KNOWLEDGE BASE
Log In    |    Knowledge Base    |    4D Home
Tech Tip: Preventing Web form data from being truncated
PRODUCT: 4D | VERSION: 6.8 | PLATFORM: Mac & Win
Published On: November 15, 2002

Compatibility: Version 6.7.x and 6.8.x

The 4D Web server follows an undocumented rule that affects how form submissions are handled within 4D:

Forms submitted with POST must start with /4DCGI/ or /4DACTION/.

If this rule is not followed, 4D strips the form data out of the request header before any custom code in the database runs. Therefore:

- GET WEB FORM VARIABLES builds arrays with no elements.
- $2 in On Web Authentication includes no form data.
- $2 in On Web Connection includes no form data.

Understanding this 4D rule requires a bit of background about HTML forms. Form requests can be submitted to a Web server using either of two HTTP request methods: GET or POST. The method selected has no effect on how the form appears but changes how the browser formats the request to the server. Below are sample definitions of a form using GET and POST. The only difference between the two is the method specified, highlighted in bold below:










GET POST
<form   action="/4dcgi/search" method="get">



<input type="text" name="searchValue"   value="">



<input   type="submit" name="submit" value="Search">

<form action="/4dcgi/search" method="post">



<input type="text" name="searchValue" value="">



<input type="submit" name="submit" value="Search">





When submitting the form with GET, the browser adds all of the form's fields together and submits them as a single URL:

GET /4dcgi/search?searchValue=acme+black+dot&submit=Search HTTP/1.1

Using POST, the browser organizes the request headers and form data in distinct sections:

POST /4dcgi/search HTTP/1.1
Content-type: application/x-www-form-urlencoded
Content-length: 40

searchValue=acme+black+dot&submit=Search

The 4D Web server handles these two requests identically. If, however, the form request starts with anything other than /4DACTION/ or /4DCGI/, 4D strips out the form data from the version submitted with POST. This behavior can be frustrating to debug as it's not obvious if the problem is in the browser, in the network connection, or in 4D. Common reasons for encountering this behavior are either that a URL is misspelled accidentally or the /4DCGI/ or /4DACTION/ request keywords are deliberately avoided.

There are several approaches to managing 4D's requirements for forms submitted with POST:
- Start requests with /4DACTION/ or /4DCGI/.
- Submit forms using GET instead of POST.
- Submit forms to another Web server, like 4D WebSTAR, and use a rewrite module to reformat URLs as 4D requires.