Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#191 closed defect (fixed)

Petascope response mimetype is text/plain

Reported by: mase@… Owned by: msahakyan
Priority: major Milestone: 8.4
Component: petascope Version: 8.3
Keywords: Cc: j.yu, dmisev, barboni@…
Complexity:

Description

GetCapabilities?, DescribeCoverage? and GetCoverage? (where returning GML Coverage format rather than image format) set the response Content-Type to text/plain rather than application/xml (or other XML mime type).

This means, for example, that an XMLHttpRequest object will have null as the responseXML.

Change History (13)

comment:1 Changed 5 years ago by dmisev

  • Owner changed from dmisev to msahakyan
  • Status changed from new to assigned

Another simple fix needed probably in PetascopeInterface?

comment:2 Changed 5 years ago by msahakyan

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:3 Changed 5 years ago by dmisev

  • Cc j.yu added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Seems like the mime-type of GetCapabilities/DescribeCoverage? should be application/xml. What about GetCoverage??

Jinsongdi, please confirm.

comment:4 Changed 5 years ago by j.yu

It should be application/gml+xml for getCoverage

comment:5 Changed 5 years ago by dmisev

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:6 Changed 5 years ago by pcampalani

But this way browsers do not visualize it, and return a file: not so convenient.

Reopening the ticket since the MIME type is anyway not coeherent between GetCoverage (now application/gml+xml) and DescribeCoverage/GetCapabilities (text/xml).

I think we should choose a MIME type which is recognized by the browsers as text.
Would text/xml be wrong for some reason?

comment:7 Changed 5 years ago by pcampalani

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 5 years ago by pcampalani

  • Cc dmisev barboni@… added

comment:9 Changed 5 years ago by dmisev

text/xml is visualized fine for me in firefox?

The GetCoverage? must be application/gml+xml according to the standard I guess.

comment:10 Changed 5 years ago by mase

Since originally submitting this ticket I have found quite a bit of inconsistency in different browsers parsing XML responses for which I haven't resolved the reasons. So I don't know how strong an argument about the XMLHttpRequest object I made in the initial ticket is anymore.

However, from a standards point-of-view...

Other OGC standards seem to have changed their ideas on this, they used to have OGC specific mimetypes which people hated I think for the same reason Piero would like text/xml; so it appears in a browser.

(By the way, in Firefox at least if you ask it to open a returned file which has one of these non-standard mimetypes in Firefox itself then it will display them. So it's not such a problem.)

However, text/xml is deprecated (http://lists.w3.org/Archives/Public/www-html/2004Jul/0004.html). I suspect this was a controversial decision as text/xml types are quite convenient but I think the reasoning is to do with the way mail gatways are allowed to handle text encoding of text/* mimetypes. Possibly not so relevant for web apps?

I'm not sure what the best solution is (but not text/plain). Maybe OGC has a general policy on this now? This is really a discussion for the standards group with the software implementing whatever decision they make.

comment:11 Changed 5 years ago by mase

http://tools.ietf.org/html/draft-murata-kohn-lilley-xml-03 is more complete article about deprecating text/xml but it is only a draft so maybe not authoritative and there doesn't seem to be a solution that works well in all cases.

comment:12 Changed 5 years ago by pbaumann

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:13 Changed 5 years ago by pcampalani

If text/xml is deprecated then we should change the MIME type of GetCapabilities and DescribeCoverage responses.

Moving discussion to dev mailing list and coming back with conclusions.

Note: See TracTickets for help on using tickets.