We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I'm trying to do some tests of the AJAX feature of the embedded HTTP server (MDK 5.1.6 Network Component). The thing is, the server is always sending the HTTP header:
Server: Keil-EWEB/2.1 Content-Type: text/html Cache-Control: no-cache Connection: close
The problem is that, without
Connection: "keep-alive"
the TCP connection is being opened and closed for every refresh of an AJAX object, so the performance is not good when trying to refresh some page content, in spite of using AJAX.
Is there a way of overriding this in the HTTP Response header??
Regards.
It might just be that Keil's server doesn't support persistent connections since it wasn't part of the original HTTP/1.0 standard. And lots of And lots of smaller HTTP servers implements only HTTP/1.0 or some sub-set of newer standards to save on code size and complexity.
Thanks for your reply. It might be so... Since the embedded web server is able to send
Content-Type: text/xml
under certain conditions, they may have just added applications like AJAX or SOAP to its portfolio of "supported technologies". However, their application in real world is arguable if the implementation is subject to HTTP/1.0
In my case, what I am trying to do is using AJAX for refreshing data on certain web page fields with AJAX, so that the whole page mustn't be reloaded. But, what is the benefit of doing that, if the TCP connection must be re-established all the time?
stackoverflow.com/.../how-keep-alive-of-http-can-is-play-role-in-ajax-application
AJAX doesn't require persistent connections. The persistence gives less network and CPU load for the web server, which often isn't important for an embedded device. A big web server with thousands of concurrent users on the other hand, might require that support to survive the hammering of all users. For AJAX, it's more important how the server can produce dynamic content instead of just emitting pre-generated files.
And you can serve whatever Content-Type without really affecting the web server - unless you need on-the-fly compression of the data.
And just so you know - I haven't checked what HTTP protocol version Keil's server claims to support - I have own HTTP server code that I use in both embedded devices and in PC programs. But feel free to look at the full response header, what HTTP version it claims.