-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output mimetype for processes not set correctly #130
Comments
Adding application/x-netcdf to mime.types file allows the file to be correctly queried for its mimetype. Cannot confirm that this is the source of the problem we experience at the moment, where an input NetCDF file coming from wpsoutput cannot be fed to another WPS process in input. |
i've looked into the error message in the log:
I have enabled lineage info (listing inputs and outputs in wps result document) and it failed to get the mimetype keyword when listing the complex outputs. I'm not aware that pywps 3.x does any validation of the input ... this is introduced with pywps 4.x. In pywps 3.x when you provide a url it will just download it ... no matter what :) The wps output files are living on an nginx file server. I haven't got deeper into this ... but two things we can do:
|
by accident i've entered a broken url (http missing) and i got the "mimetype" exception. Maybe it is a follow up exception when a url is not reachable during the download? |
When running a job through Pyramid, the output mimetype is fetched from the WPS complex output and displayed correctly. This is the case for most NetCDF outputs. Querying the mimetype for the file through its URL does not produce the same result. For instance, for this job:
https://mouflon.dkrz.de/monitor/details/e7977e440f854d34826ef6f1957bfe2a/outputs
When querying the mimetype for the output with CURL, we obtain "application/octet-stream" instead of "application/x-netcdf":
H:>curl -I -L http://mouflon.dkrz.de:8090/wpsoutputs/flyingpigeon/ncout-241b8e4
4-9a16-11e6-ae00-1f4eae89de9f.nc
HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Fri, 25 Nov 2016 18:21:10 GMT
Content-Type: application/octet-stream
Content-Length: 7628716
Last-Modified: Mon, 24 Oct 2016 18:18:19 GMT
Connection: keep-alive
ETag: "580e506b-7467ac"
Accept-Ranges: bytes
The text was updated successfully, but these errors were encountered: