Socket Behavior in the HTTP Mode

When in the HTTP mode, the socket behaves differently compared to the normal data mode.

Incoming Connection Rejection

As was explained in Accepting Incoming Connections, if your device "decides" to reject an incoming TCP connection, it will send out a reset TCP packet. This way, the other host is instantly notified of the rejection. The rules are different for HTTP sockets:

• If there is an incoming TCP connection to the web server of the device (incoming HTTP connection request), your application has one or more sockets that are configured to accept this connection, and if all such sockets are already occupied, then the system will not reply to the requesting host at all.
• If there is an incoming HTTP connection request and your application has no HTTP sockets configured to accept this connection, then the system will still respond with a reset.

This behavior allows your application to get away with fewer HTTP sockets. Here is why: If all HTTP sockets are busy and your application sends out a reset, the browser will show a "connection reset" message. If, however, your device does not reply at all, the browser will wait and resend its request later. Browsers are "patient" — they will typically try several times before giving up. If any HTTP sockets are freed up during this wait, the repeat request will be accepted and the browser will get its page. Therefore, a few HTTP sockets can handle a large number of page requests in a sequential manner and with few rejections.

Other Differences

• All incoming data is still stored in the TX buffer (yes, the TX buffer). This data, however, is not passed to your program but, instead, is interpreted as an HTTP request. This HTTP request must be properly formatted. The sock. object supports GET and POST commands.
• The RX buffer is not used at all and does not have be allocated any memory.
• GET and POST commands can optionally contain "request variables." These are stored into the VAR buffer, from which your program can read them out later.
• No on_sock_data_arrival event is generated when an HTTP request string is received into the RX buffer.
• Once the entire request has been received, the socket prepares and starts to output the reply. Your program has no control over this output until a Tibbo BASIC/C code fragment is encountered in the HTTP file. The on_sock_data_sent event cannot be used as well.
• When a code fragment is encountered in the HTTP file, control is passed to it and then your program can perform a desired action (e.g., generate some dynamic HTML content, etc.). When this fragment is entered, sock.num is automatically set to the correct socket number.
• Once an HTTP reply has been sent to the client, the socket will automatically close the connection, as is the normal socket behavior for HTTP. A special property — sock.httpnoclose — allows you to change this default behavior and leave the connection opened.