Thanks Mark! The HTTP server I am building is a server that provide dynamic data (format can be binary or text, size can vary from MB to TB) according to requests of users. The server is supposed to serve user scripts (e.g., in perl/python/java/c#) and browsers (e.g., ie). The expected solution would be the client can get aware of the error immediately (not waiting for timeout and knowing the data is incomplete). Ideally, users should be notified this is an internal error and they should contact admin instead of repeating the request. Also, since this is a well known problem with HTTP, what are the general approaches recommended? It will be great if some previous discussions about this topic can be pointed to me. Again, thanks a lot! Mark Baker <[EMAIL PROTECTED]> wrote: This is a well known problem with HTTP.
You should probably ask yourself what it makes sense for clients to do in case of an error in your server/content, and then try to figure out how to induce that behaviour. If you could provide more detail about your application/content, I might be able to give more specific advice. Mark. On 9/12/07, X. Long wrote: > Hi, I am developing a HTTP server and most of requests the server gets are > for large size contents that are dynamically generated. > > Currently, the server is responsing in the following way: 1) upon receiving > a request for object A, it constructs and sends a resposne header with > status code 200 (of course no content-length specified) if the object is > valid; 2) generates and buffers contents and sends buffered contents by HTTP > chunk transfering. > > The problem here is how to handle potential errors during contents > generation in the server. Since a 200 response has already been sent, I > cannot send another response with another status code. > > I can (i) close the connection but the clients (e.g., IE) will just end as > the entire data have been received. (2) send nothing and wish clients will > timeout themselves. But it seems dangurous that there are chances some > clients will be hanging there for a very long time. > > I am wondering what the "standard" way the server is expected to behavior > under such situation. Any comments are welcomed and appreciated! > > ________________________________ > Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. > > -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.
