parameters with defaults but user forced to provide them?

[megies]

Maybe I am missing something, but the specs seem to specify default values for all parameters, even those that usually in implementations will not be left wildcarded by default. In dataselect that applies to starttime and endtime. I think, it will be hard to come up with a use case where it makes sense to leave them wildcarded (maybe some obscure very short lived temporary installment, so an extreme edge case). Naturally e.g. Earthscope will return an error message if starttime or endtime is not specified.

Maybe the specifications should also state which parameters need to be specified by the user, i.e. are without default values?

We recently had an instance of a production server dealing FDSN WS availability brought to its knees by a user sending multiple requests matching large parts of the complete DB (/fdsnws/availability/1/extent?network=BW). For sure this is also a problem of the implementation not stopping a humongous request earlier before filling up the RAM+SWAP almost completely. But I think being clearer on what parameters need to be provided by the user would be good for the specs and then the implementations following them accordingly.

[crotwell]

Deciding how big of a request is too big is pretty challenging, and I'm not sure simply making parameters be required fixes it. Although I agree it is hard to come up with a use case with starttime and endtime left out, perhaps at least starttime should be required. Just a note, the result for your example would be just as bad if the starttime was given as year 1900 and endtime was now.

Perhaps instead of specifying required parameters, it would be better to add a note that implementations should estimate the data volume of a request and fail if it is too big, perhaps with a 413 "Content Too Large" HTTP status code and must explain any limits in the service documentation. An example might be that the server multiplies number of matching stations/channels and time window given, and if this is bigger than X hours, fails.

Earthscope currently says "The service now limits the volume of miniSEED data that will be returned with a single query. We recommend limiting requests to one station for a 24-hour period at the most." which more or less aligns with this although I have definitely done larger queries so unsure what the true limit is. And getting an hour of data for one earthquake at perhaps dozens of stations seems like an acceptable use, so maybe this is too restrictive as one query for many channels may be more efficient than dozens of queries for single channels.

[crotwell]

Just note I missed this, but in the commonalities spec it says:

Result set limitations
Limitations on the amount of information returned for any given request may be imposed
independently for each service by each data center. If a client submits a request that would result in a
data set beyond the service limit the service should return an HTTP status 413 (Request Entity Too
Large). A 413 should also be returned when the request itself is too large, the standard meaning of the
status. In most cases, differentiating between these two cases will be obvious

so the 413 for too big is already there.

[megies]

the result for your example would be just as bad if the starttime was given as year 1900 and endtime was now.

Agreed 100%, you can never safeguard like that from bad requests. But it's always very tempting for users to leave out everything that they are allowed to leave out. And potentially having to fill in something makes users think about what would be appropriate to put there 🤷

I kind of mostly left this here as a comment and food for thought after debugging why our server went unresponsive. But still the specs are quite detailed in many things but whether some parameters are required to be specified explicitly or not seems left floating kind of.