Hey all,
So the WFS, in general, doesn't indicate via response mime type whether
a request was processed successfully or not.
The WFS 1.0.0 spec is relatively mum on the use of mime types. I
haven't checked the 1.1.0 spec yet.
The WMS spec, on the other hand, does lots with mime types in the area
of exception reporting.
Anyone have any strong ideas about whether the WFS should set a response
mime-type of 'application/vnd.ogc.se_xml' on responses that have
generated a serviceException?
I'd vote in that direction (for consistency with WMS) but I just thought
I'd bring it up since I ran across the question just now.
--saul
I actually sorta hate how WMS does custom mime types for errors, and for capabilities. The reason is because when you're testing things through the browser it won't just display the xml, because it's an unknown mime type.
WMS 1.3 actually fixes this, mime types for errors are supposed to be text/xml. So OGC has been moving away from doing lots of weird mime types.
I suppose we could do something like text/xml; subtype=vnd.ogc.se_xml Which would let a client know an error from the mime type, while also letting browsers properly display the xml.
Chris
Saul Farber wrote:
Hey all,
So the WFS, in general, doesn't indicate via response mime type whether
a request was processed successfully or not.
The WFS 1.0.0 spec is relatively mum on the use of mime types. I
haven't checked the 1.1.0 spec yet.
The WMS spec, on the other hand, does lots with mime types in the area
of exception reporting.
Anyone have any strong ideas about whether the WFS should set a response
mime-type of 'application/vnd.ogc.se_xml' on responses that have
generated a serviceException?
I'd vote in that direction (for consistency with WMS) but I just thought
I'd bring it up since I ran across the question just now.
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,47211e6542641030819293!
Great answer chris.
If WMS is moving away from the specialized mime-types in WMS 1.3.0, then
that's great. Combined with your point about browsers being unable to
handle responses because of weird mime-types, I'm doubly convinced.
--saul
On Fri, 2007-10-26 at 10:21 -0400, Chris Holmes wrote:
I actually sorta hate how WMS does custom mime types for errors, and for
capabilities. The reason is because when you're testing things through
the browser it won't just display the xml, because it's an unknown mime
type.
WMS 1.3 actually fixes this, mime types for errors are supposed to be
text/xml. So OGC has been moving away from doing lots of weird mime types.
I suppose we could do something like text/xml; subtype=vnd.ogc.se_xml
Which would let a client know an error from the mime type, while also
letting browsers properly display the xml.
Chris
Saul Farber wrote:
> Hey all,
>
> So the WFS, in general, doesn't indicate via response mime type whether
> a request was processed successfully or not.
>
> The WFS 1.0.0 spec is relatively mum on the use of mime types. I
> haven't checked the 1.1.0 spec yet.
>
> The WMS spec, on the other hand, does lots with mime types in the area
> of exception reporting.
>
> Anyone have any strong ideas about whether the WFS should set a response
> mime-type of 'application/vnd.ogc.se_xml' on responses that have
> generated a serviceException?
>
> I'd vote in that direction (for consistency with WMS) but I just thought
> I'd bring it up since I ran across the question just now.
>
> --saul
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4005,47211e6542641030819293!
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel