POST request: floating point issue

[damb]

Hi all,

sending POST requests to a WFCatalog webservice instance (e.g. www.orfeus-eu.org/eidaws/wfcatalog/1/query) results in an ERROR 400. The issue seems to be valid for all parameters specified as xs:float at the application.wadl file. Bellow an example for the max_gap_gt parameter:

The request was set up as described at http://www.orfeus-eu.org/data/eida/webservices/wfcatalog/. The content of the postfile is:

$ cat wfcatalog.request 
max_gap_gt=5.0
NL HGN * * 2017-01-01 2017-01-07

$ wget -O - -v --post-file wfcatalog.request http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
--2017-11-01 13:51:15--  http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
Resolving www.orfeus-eu.org (www.orfeus-eu.org)... 145.23.3.20
Connecting to www.orfeus-eu.org (www.orfeus-eu.org)|145.23.3.20|:80... connected.
HTTP request sent, awaiting response... 400 The submitted POST body is invalid
2017-11-01 13:51:15 ERROR 400: The submitted POST body is invalid.

The request is successful in case of omitting the floating point specification for the max_gap_gt parameter i.e. max_gap_gt=5:

$ wget -O - -v --post-file wfcatalog.request http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
--2017-11-01 14:18:23--  http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
Resolving www.orfeus-eu.org (www.orfeus-eu.org)... 145.23.3.20
Connecting to www.orfeus-eu.org (www.orfeus-eu.org)|145.23.3.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘STDOUT’

-                       [<=>                 ]       0  --.-KB/s               [{"version":"1.0.0","producer":{"name":"ORFEUS ODC/KNMI","agent":"ObsPy mSEED-QC","created":"2017-01-07T05:02:08.192Z"},"station":"HGN","network":"NL","location":"02","channel":"BHZ","num_gaps":2,"num_overlaps":2,"sum_gaps":7.850001000000001,"sum_overlaps":0.05,"max_gap":5.125039,"max_overlap":0.025,"record_length":[512],"sample_rate":[40],"percent_availability":99.99091435069445,"encoding":["STEIM2"],"num_records":8695,"start_time":"2017-01-06T00:00:00.000Z","end_time":"2017--                       [ <=>                ]     537  --.-KB/s    in 0s      

2017-11-01 14:18:23 (6.37 MB/s) - written to stdout [537]

However, this behaviour seems to be against the specifications i.e. https://github.com/EIDA/wfcatalog/blob/master/wf_metadata_schema.json.

I can exclude an encoding issue since for a postfile with

$ cat wfcatalog.request 
max_gap_gt=5
NL HGN * * 2017-01-01 2017-01-07T00:00:00.000

it seems to work properly:

$ wget -O - -v --post-file wfcatalog.request http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
--2017-11-01 14:10:10--  http://www.orfeus-eu.org/eidaws/wfcatalog/1/query
Resolving www.orfeus-eu.org (www.orfeus-eu.org)... 145.23.3.20
Connecting to www.orfeus-eu.org (www.orfeus-eu.org)|145.23.3.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘STDOUT’

-                       [<=>                 ]       0  --.-KB/s               [{"version":"1.0.0","producer":{"name":"ORFEUS ODC/KNMI","agent":"ObsPy mSEED-QC","created":"2017-01-07T05:02:08.192Z"},"station":"HGN","network":"NL","location":"02","channel":"BHZ","num_gaps":2,"num_overlaps":2,"sum_gaps":7.850001000000001,"sum_overlaps":0.05,"max_gap":5.125039,"max_overlap":0.025,"record_length":[512],"sample_rate":[40],"percent_availability":99.99091435069445,"encoding":["STEIM2"],"num_records":8695,"start_time":"2017-01-06T00:00:00.000Z","end_time":"2017--                       [ <=>                ]     537  --.-KB/s    in 0s      

2017-11-01 14:10:10 (6.10 MB/s) - written to stdout [537]

GET requests are resolved successfully. The issue is reproducible also when using curl.

cheers

[Jollyfant]

Hi damb, thanks for the report. I have committed a small change that should allow floats too.

57d800c closes this issue.

[damb]

@Jollyfant, can we close this one, here? It would be good to provide a new release (actually an initial one) such that EIDA nodes can deploy the most recent version. Thanks.

CC @jbienkowski