RE: How to handle errors if contents of response are dynamically generated?

Hi

 

There is no standard way of handling this situation. Once you have committed
to sending the data, and your server subsequently encounters a problem, then
you have very little option but to close the connection. You cannot assume
the client will ever timeout and you cannot really be accountable for what

 

According to the specification, the OPTIONAL chunked trailer. (3.6.1)
"allows dynamically produced content to be transferred along with
information necessary for the recipient to verify that it has received the
full message"

 

If you have some influence over the way the client processes the messages,
then you could do a number of things, for example

 

-          Send a Content-Length trailer (ref issue in 4.4-3)

-          Send an X- header trailer indicating a closure without completion


 

One would have thought that a -1 (or some other indicator value for example)
instead of chunked size could have been used together with some additional
text to indicate a failure.

 

--Greg

 

  _____  

From: www-talk-request@w3.org [mailto:www-talk-request@w3.org] On Behalf Of
X. Long
Sent: Friday, 14 September 2007 5:11 AM
To: Mark Baker
Cc: www-talk@w3.org
Subject: Re: How to handle errors if contents of response are dynamically
generated?

 

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 <distobj@acm.org> 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
<http://us.rd.yahoo.com/evt=48252/*http:/mobile.yahoo.com/mobileweb/onesearc
h?refer=1ONXIC>  search that gives answers, not web links.