<div class="gmail_quote">On Mon, Apr 9, 2012 at 4:29 PM, Roland Olbricht <span dir="ltr"><<a href="mailto:roland.olbricht@gmx.de">roland.olbricht@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am Freitag, 30. März 2012 11:15:26 schrieb Peter Wendorff:<br>
> Hi.<br>
> In a software I'm going to use the Overpass-API to fetch OSM-Data, and I<br>
> think about handling error codes.<br>
> As far as I see, Overpass prints errors in a <remark>-Tag in human<br>
> readable text, but nowwhere as machine-readable text, while most error<br>
> codes I guess could be mapped on HTTP-response states.<br>
<br>
Well, I'm not sure whether HTTP-response codes are here the best way to encode<br>
error states. The by far most important error situations are<br>
1. A timeout on the server<br>
   The client shouldn't use the result, as it may be incomplete. It can retry<br>
   with a longer timeout.<br>
2. Connection refused<br>
   This would happen in case of overload, does happen rarely at the moment,<br>
   but it should be addressed by a client. The client should retry after a<br>
   timespan of 1 to 5 seconds again.<br>
3. A malformed request<br>
   It would be unusual if this happens when the request is generated<br>
   programmatically. If a human user has entered the query, the client should<br>
   pass the HTML document to the human user.<br></blockquote><div><br></div><div>All of these have analogues in HTTP error codes. #1 and #2 should probably be HTTP 5xx (because it's a server problem) and #3 should be an HTTP 4xx of some sort (because the client did something wrong).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The more simpler approach would be to process the result if it is OSM XML and<br>
to pass it to the end user if it is HTML.<br>
<br>
Specifically the first one cannot be handled by a HTTP status code. The status<br>
code is always the first thing to be written. Thus, to send a different HTTP<br>
status code in case of a timeout, the servers needs to held back the payload<br>
until the request has been completed. That impedes a couple of use cases where<br>
the client could take advantage of early arriving responses. Thus, a response<br>
started with HTTP 200 may still fail later with a timeout.<br></blockquote><div><br></div><div>You shouldn't write your response out until it's ready. If you want to return the HTTP header quickly then you should respond with a "polling URL" that the client can check for the result when it's finished.</div>
</div>