315
TIDE and Tibbo BASIC User Manual
©2000-2008 Tibbo Technology Inc.
transmitted data (HTTP reply).
In the simplest case the file returned to the web browser is static- a "fixed" HTML
page, a graphic, or some other file. Processing of such a static file requires no
intervention from your program whatsoever. Just setup the socket(s) to be able to
accept HTTP requests and the sock object will take care of the rest.
More often than not, however, you have to create a dynamic HTML page. Dynamic
pages include fragments of BASIC code. When the sock object encounters such a
fragment in the file being sent to the browser, it executes the code. This code, in
turn, performs some action, for example, generates and sends some dynamic data
to the browser or jumps to the other place in the HTML file.
The HTTP server built into the sock object understands two request types- GET and
POST. Both can carry "HTTP variables" that the server will extract and pass to the
BASIC code.
At the moment, the following file types are explicitly supported:
HTML- can be static or include BASIC code.
TXT- plain text, no BASIC code can be included.
JPG and GIF- graphic files.
All files other than HTML files are static and are sent to the browser "as is". There
is, however, a method of programmatic generation of such files -- see
.
All other file types are handled as binary files.
Currently, the socket object can only access first 65534 bytes of each
HTML file, even if the actual file is larger! Make sure that all HTML files
in your project are not larger than 65534 bytes. This is not to be
confused with the size of HTTP output generated by the file. A very
large output can be generated by a small HTML file (due to dynamic
data generation)- and that is OK. What's important is that the size of
each HTML file in your project does not exceed 65534 bytes.
65534 is actually the size limitation for the compiled HTML file. When
compiling your project, the TIDE will separate the static portion of the
file from the Tibbo Basic code fragments. Only the compiled file size
matters.
HTTP-related Buffers
For the HTTP to work, you need to allocate some memory to the following buffers:
RX buffer. This buffer will be receiving HTTP requests from the client (browser).
Buffer allocation request is done through the
method. It is
possible to avoid spending memory on the RX buffer by
this buffer
to the TX buffer of the same socket. This will work because the web server
operation is strictly sequential -- receive a request, then generate a reply.
Requests and replies do not have to be stored concurrently, so one buffer is
sufficient and you will save some memory!
TX buffer. This buffer will be handling web server replies. If you enable
redirection it will also receive HTTP requests. Buffer allocation request is done
through the
method. Practical experience shows that allocating
just one page for this buffer makes HTTP request handling somewhat slow. At
322
350
308
362