Can formatTypes be extended to have a CSV type?

[seismopaul]

I am confused if the formatTypes are restricted to those in the list defined in the documentation, namely the ones included below. Is it possible to add a type of CSV?

When i put format=csv and have a handler that returns CSV data for our web service, the browser barfs with the error shown below:

This page contains the following errors: error on line 1 at column 1: Document is empty Below is a rendering of the page up to the first error.

even if I map CSV to text/plain the browser doesn't recognize the return from the WSS. Do I need to spoof the return of csv files somehow so they are sent to files instead? If so, how do I manage that with the WSS and my handler?

Note that my web service if used with wget or curl returns the CSV files just fine and if in the browser I say "View Source" on the given page, I see the CSV. There is something in the return headers that just isn't working for the browser to see it or send it to a file. What am I missing.

I currently have the following settings in my service.cfg file:

formatTypes - specifies a list of "formatType: mediaType" pairs

query.formatTypes = \ xml: application/xml,\ csv: text/plain,\ text: text/plain,\ json: application/json

Content-Disposition overrides for respective media types "text" and "miniseed"

query.formatDispositions= \

text: inline; filename="mypart${appName}${UTC}.txt", \

miniseed: attachment; filename="a_miniseed_file.mseed"

query.formatDispositions= \ text: attachment; filename="${appName}${UTC}.csv",\ csv: attachment; filename="${appName}${UTC}.csv",\ zip: attachment; filename="data.zip"

List of "allowed?" format types extracted from HandlerRequirements.md write up: formatType Media type xml application/xml mseed application/vnd.fdsn.mseed text text/plain texttree text/plain json application/json binary application/octet-stream

[mickvf]

Hi there: This is weird and I will try to debug with a repro case as soon as I can get to it. In the meantime, is this behavior browser-dependent by any chance? I know chrome and safari differed in how they handled CSV by default, but still you're getting the "doc is empty" error. Weird.

As for spoofing, I have a web service that returns geocsv as an option. For the "&format=geocsv" case I force a gzip file download like so (in the service.cfg file)

model.formatTypes = \
    geocsv: application/x-gzip,\
    netcdf: application/netcdf,\
    zip: application/zip

I will also look at another possibility (or clue) - the method processStream() is overloaded. I haven't used that version but looks like, from Mike's code comments, you can pass a 3rd argument to override the response headers created by WSS:

IrisProcessingResult processStream(StreamingOutput so,
     String wssMediaType, 
     Map<String, String> headers)

More to come. -Mick

[mickvf]

OK I repro'd this and here are 2 findings which I think will work for you:

(1) The bit about the service only recognizing the first format listed: As "luck" would have it my test service for the CmdProcessor style of WSS had an errant prefix in front of the "formatTypes = ..." section in service.cfg

query.formatTypes: query.formatTypes = \ xml: application/xml,\ text: text/plain, \

The text in BOLD with the colon (query.formatTypes:) was causing the issue with the service only recognizing the first format type. There may be other ways to cause this problem, but once I took that away, the problem disappeared. (I will plow thru the docs to see where that errant string may have originated)

(2) Re the CSV issue. I think this is indeed browser specific. I think you should try something like this in service.cfg, including the formatDisposition section:

query.formatTypes = \ 
xml: application/xml, \ 
text: text/plain, \ 
zip: application/zip, \ 
csv: text/csv

query.formatDispositions= \ 
zip: attachment; filename="data.zip", \
csv: inline; filename="data.csv"

Note the inline disposition for csv. This will ask the browser "pretty please" render the content in the browser window if you support this. Chrome does not so it is handled as an attachment. Safari seems to oblige however.

Don't be like me and forget to restart Tomcat with CFG changes =D

Here is some more detail on service.cfg

Hope I was able to help you! -Mick

[seismopaul]

Hi Mick,

Here is what we had for our tomcat config with WSS that finally worked for us with CSV as files. Note we did not have he issue with your #1 with an errant prefix. I checked for spaces after the \ delimiters and that was not it either. Furthermore, it is still only processing the first item in the list...Now even XML format output gets attempted to be downloaded as the csv file...It seems the list parser in WSS is very very fickle and broken. We cannot get it to recognize anything but the first element!!!

This is still a mystery for us. Here below are our lines cut and pasted from the service.cfg file:

query.formatTypes = \ csv: application/octet-stream, \ json: application/json, \ text: text/plain, \ xml: application/xml

query.formatDispositions= \ text: inline; filename="${appName}${UTC}.csv", \ csv: inline; filename="${appName}${UTC}.csv", \ zip: attachment; filename="data.zip"

Paul

[seismopaul]

Note that the github editor handily removed the back slash characters before the newlines......and now won't let me edit the last comment.....

Paul