<div dir="ltr"><div><br></div><div>Hi<br><br></div>Following up on my inability to catch a 204, can you explain the rationalization
for using a 204 instead of returning an empty, but structurally correct,
quakeml document for a query that doesn't match anything. For example is I ask for a time window and magnitude range that doesn't match any earthquake, send back this:<br><br><q:quakeml xmlns:q="<a href="http://quakeml.org/xmlns/quakeml/1.2">http://quakeml.org/xmlns/quakeml/1.2</a>" xmlns="<a href="http://quakeml.org/xmlns/bed/1.2">http://quakeml.org/xmlns/bed/1.2</a>"><br>
<eventParameters publicID="smi:<a href="http://service.iris.edu/fdsnws/event/1/query">service.iris.edu/fdsnws/event/1/query</a>"><br></eventParameters><br></q:quakeml><br><br>To
be honest, I would rather have an empty XML document returned in the
case where the query is well formed and valid, but just so happens that
nothing in the database matched my query. HTTP error codes make it sound
like there was an error, but that is not really the case here. There
wasn't any data and so an empty xml document is a fine thing to return. <br><br>I
had a quick read of the http spec, and it doesn't really sound to me
like a 204 is actually meant to mean, "sorry, no data", but rather is to be used in
cases where there is some communications efficiencies to be had by
avoiding a "entity body" and a update of the document view.<br><br>I guess I just don't see
any advantage of 204 being the default for "no data" for these xml web services, especially when it
will almost certainly cause confusion given the way browsers handle it,
ie leaving the old page content on the display. <br><br>$0.02<br>Philip<br><br><br><br></div>