Socket Behavior in the HTTP Mode
|Top Previous Next|
When in the HTTP mode, the socket is behaving 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. Rules are different for HTTP sockets:
•If there is an incoming TCP connection to the web server of the device (incoming HTTP connection request), and if 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 if 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, very few HTTP sockets can handle a large number of page requests in a sequential manner and with few rejections.
•All incoming data is still stored in the TX buffer (yes, TX buffer). This data, however, is not passed to your program but, instead, is interpreted as 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 the HTTP request string is received into the RX buffer.
•Once entire request has been received the socket prepares and starts to output the reply. Your program has no control over this output until a BASIC code fragment is encountered in the HTTP file. The on_sock_data_sent event cannot be used as well.
•When code fragment is encountered in the HTTP file control is passed to it and then your program can perform desired action, i.e. generate some dynamic HTML content, etc. When this fragment is entered, the sock.num is automatically set to the correct socket number.
•Once HTTP reply has been sent to the client the socket will automatically close the connection, as is a normal socket behavior for HTTP. A special property- sock.httpnoclose- allows you to change this default behavior and leave the connection opened.