[Geoserver-devel] Web Browsers and POST - impossible!

Okay, I've spent the last little while looking at how to actually do OGC
webservices via a web browser. ITs much more difficult that you might
think.

As far as I can tell, its pretty much impossible to do WMS SLD-POST, and
difficult to do WFS posts.

1. WFS GET -- no problems (but reading the XML response can be difficult
- see #3 if you're expecting to parse the response in the browser)
2. WMS GET -- no problems

3. WFS POST

    These are all doable with the XMLHttpRequest object because it sends
XML and receives XML.

    The main problem is browser security - you MUST have your
"controlling" html document and the WFS coming from the same host or
you'll get a security exception. This also means you can only talk to
one WFS at a time and you need to have the client html code originate
from the same server! Quite a bit of a hastle...

4. WMS SLD POST

     As far as I can tell, this is neigh near impossible to do well from
a browser. I tried really hard to get this to work with an <iframe>.
Unfortunately, once the image is in the iframe, you cannot get it out,
and its a bit difficult to actually use when its inside an iframe
(instead of in a controllable <IMG> or <a><IMG></a>).

     NOTE: when you actually try to get the image out of an iframe, your
browser will make a GET (NOT a POST) request to re-get the image - this
has no chance of working!!

From what I can tell the MapBuilder people have gotten around this by:
   1. not using SLD POST (As far as I can tell, geoserver is the only
WMS server to support it)
   2. using a WFS proxy to so the XMLHttpRequest doesn't have security
issues.

I've also noticed a few other issues;

1. POST isn't POST.

   When you do <form action=POST...><input type=hidden name=XML> in
HTML, you'll get a request that has something like this in the body:

   XML=<url encoded version of your XML>

   (you can also use encType="multipart/form-data" for form data, which
has a nicer encoding)

   Unfortunately, the WFS POST systems expect a more SOAP-like encoding.
The body is just "plaintext" XML.

   These 2 ways arent compatible.

   SOLUTION: make all the Geoserver POST handlers handle all the
different encodings. At the very least, make the WMS POST handler work
with the SOAP-like encoding and the <form action=POST> encoding.

2. Handling WMS SLD-POST via a GET.

   Gabriel had a suggestion very much like this (its also how the
original Mapserver non-WMS interface works). There's two major
possibilities:

   a) instead of sending a request to the wms "getmap" service, send the
exact same request to another servlet. It takes your GetMap POST XML
and converts it into a HTTP GET request and saves the SLD locally. It
responds with an address with a "&SLD=<local temp file>". The client
can then use this address to grab the image.

   ** If you just return the URL query string, you can have this proxy
and the .html file on the same server, getting you around security
issues. The web browser can then just appends the query string onto
the WMS server address and make the request. This seems to be the most
"compatible" method, but there's a lot of round-trips!

   ** The complexity of this can be all hidden away in a single
JavaScript function.

  ** This would be like a temporary "PutStyle" request

   b) send the POST normally, but ask for the output format to be
"indirect/png" or "indirect/jpg". The server renders the image
normally, and saves the resulting image on the server. It returns a
simple address where you can use HTTP GET to retrieve the result.

   ** The complexity of this can be all hidden away in a single
JavaScript function.

I'm actually really suprised that they havent actually made all this
easier to do.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

Dave,
Thanks for all this great research.

1. I think one thing we need to ask ourselves is how much functionality do we really want to cram into the JS application.
The JS application will be good for a non technical user to do some cool stuff with maps, but it will never be as powerful as something like JUMP and it should not try to be.
We need to remember that all this functionality needs to be downloaded by a client.

2. For the benefit others on this list, I'm copying some lines from the IRC I have just had with you:
<CameronShorter> However, I have an idea to get round the security.
<dblasby> ah - how?
<CameronShorter> Suppose your WFS server contains a simple web page which contains an empty post form in it, ...
<CameronShorter> Then your Mapbuilder client contains a Frame which loads it's content from the above form.
<CameronShorter> You now can post to the WFS server directly through the form in the frame.
<dblasby> using the XMLHttpRequest object?
<CameronShorter> Yes.
<CameronShorter> It is not quite spec compliant because you need the above form, but it could become a defacto standard.

dblasby@anonymised.com wrote:

Okay, I've spent the last little while looking at how to actually do OGC
webservices via a web browser. ITs much more difficult that you might
think.

As far as I can tell, its pretty much impossible to do WMS SLD-POST, and
difficult to do WFS posts.

1. WFS GET -- no problems (but reading the XML response can be difficult
- see #3 if you're expecting to parse the response in the browser)
2. WMS GET -- no problems

3. WFS POST

   These are all doable with the XMLHttpRequest object because it sends
XML and receives XML.

   The main problem is browser security - you MUST have your
"controlling" html document and the WFS coming from the same host or
you'll get a security exception. This also means you can only talk to
one WFS at a time and you need to have the client html code originate
from the same server! Quite a bit of a hastle...

4. WMS SLD POST

    As far as I can tell, this is neigh near impossible to do well from
a browser. I tried really hard to get this to work with an <iframe>. Unfortunately, once the image is in the iframe, you cannot get it out,
and its a bit difficult to actually use when its inside an iframe
(instead of in a controllable <IMG> or <a><IMG></a>).

    NOTE: when you actually try to get the image out of an iframe, your
browser will make a GET (NOT a POST) request to re-get the image - this
has no chance of working!!

From what I can tell the MapBuilder people have gotten around this by:

  1. not using SLD POST (As far as I can tell, geoserver is the only
WMS server to support it)
  2. using a WFS proxy to so the XMLHttpRequest doesn't have security
issues.

I've also noticed a few other issues;

1. POST isn't POST.

  When you do <form action=POST...><input type=hidden name=XML> in
HTML, you'll get a request that has something like this in the body:

  XML=<url encoded version of your XML>

  (you can also use encType="multipart/form-data" for form data, which
has a nicer encoding)

  Unfortunately, the WFS POST systems expect a more SOAP-like encoding.
The body is just "plaintext" XML.

  These 2 ways arent compatible.

  SOLUTION: make all the Geoserver POST handlers handle all the
different encodings. At the very least, make the WMS POST handler work
with the SOAP-like encoding and the <form action=POST> encoding.

2. Handling WMS SLD-POST via a GET.

  Gabriel had a suggestion very much like this (its also how the
original Mapserver non-WMS interface works). There's two major
possibilities:

  a) instead of sending a request to the wms "getmap" service, send the
exact same request to another servlet. It takes your GetMap POST XML
and converts it into a HTTP GET request and saves the SLD locally. It
responds with an address with a "&SLD=<local temp file>". The client
can then use this address to grab the image.

  ** If you just return the URL query string, you can have this proxy
and the .html file on the same server, getting you around security
issues. The web browser can then just appends the query string onto
the WMS server address and make the request. This seems to be the most
"compatible" method, but there's a lot of round-trips!

  ** The complexity of this can be all hidden away in a single
JavaScript function.

** This would be like a temporary "PutStyle" request

  b) send the POST normally, but ask for the output format to be
"indirect/png" or "indirect/jpg". The server renders the image
normally, and saves the resulting image on the server. It returns a
simple address where you can use HTTP GET to retrieve the result.

  ** The complexity of this can be all hidden away in a single
JavaScript function.

I'm actually really suprised that they havent actually made all this
easier to do.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
mapbuilder-devel mailing list
mapbuilder-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel

--
Cameron Shorter
http://cameron.shorter.net