[Geoserver-devel] Post vs. Get in GetMap

Magne_Skjeret · November 3, 2005, 1:53am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I have a question regarding the use of post vs. get in a GetMap request.

I have set up a test in my browser:

This will give a image, while changing the "method" to "post" will not.

The doPost() method is in the GetMap servlet, while the doGet() is in
the abstract service.

The doPost() method access the input stream reader directly, and read
the body as a sequence of characters (getReader()). This is fine when
you do a url connect to http://127.0.0.1/geoserver/wms and stream the
<GetMap>/<StyledLayerDescriptor> xml directly in.

But there is no real reason why a POST with paramters should act as a
GET, as long as everything is paramterized.

e.g.

public void doPost(HttpServletRequest request, HttpServletResponse
response) {
    //If the SLD is in a paramter, and not streamed in, then just do the
    // same as GET
    if (request.getParameter("SLD_BODY") != null) {
  doGet(request, response);
  return;
     }

     //Else do as has been done untill now.
     //With complete <GetMap> streaming, or
     //partially get and post. Some get parameters and a streamed
     //<StyledLayerDescriptor> without the <GetMap> part.
}

I am not 100% sure why there is support for streaming the body directly
in, and not add them as parameters. Maybe there are some good reasons
for it?
"My" kind of post can be done both in a browser and from java code, and
it would allow you to have just one implementation for the GetMap request.

I just redirect to the doGet() method when SLD_BODY is on the url as a
parameter. Maybe there should be smarter checks? I would love to get
some input on this, if this implementation is interesting for the project.
Maybe check if all needed parameters is present, if not allow stream?

Magne

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDad6oDjwfc5lfNZcRAjCDAJwN0YZee2BWtBlrAzri+s0xNlts4gCfXjA5
Mwr3EBzCgl+RU6QnzzjqIyk=
=6FjN
-----END PGP SIGNATURE-----

Justin_Deoliveira · November 3, 2005, 7:43am

Hi Magne,

This is a known issue. And after looking into it I cant really think of a reason why post has to be directly streamed in. However one of the other developers may have a reason.

The code to handle this properly does exist in the TestWfsServlet, accessible from the demo page.

If not, I dont think it will be too hard to handle both. I am going to make a jira task for this issue.

http://jira.codehaus.org/browse/GEOS-441

It seems you have put some time in investigating this issue. Would you be interested in helping fix it, you could submit a patch if you were so inclinded.

-Justin

Magne Skjeret wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I have a question regarding the use of post vs. get in a GetMap request.

I have set up a test in my browser:

<form action="http://127.0.0.1/geoserver/wms" method="get">
        <input type="text" name="bbox" value="-130,24,-66,50"/>
        <input type="text" name="Format" value="image/png"/>
        <input type="text" name="request" value="GetMap"/>
        <input type="text" name="width" value="550"/>
        <input type="text" name="height" value="250"/>
        <input type="text" name="srs" value="EPSG:4326"/>
        <input type="text" name="styles" value="normal"/>
        <input type="text" name="layers" value="topp:states"/>
        <input type="submit" value="Get Map"/>
</form>

This will give a image, while changing the "method" to "post" will not.

The doPost() method is in the GetMap servlet, while the doGet() is in
the abstract service.

The doPost() method access the input stream reader directly, and read
the body as a sequence of characters (getReader()). This is fine when
you do a url connect to http://127.0.0.1/geoserver/wms and stream the
<GetMap>/<StyledLayerDescriptor> xml directly in.

But there is no real reason why a POST with paramters should act as a
GET, as long as everything is paramterized.

e.g.

public void doPost(HttpServletRequest request, HttpServletResponse
response) {
    //If the SLD is in a paramter, and not streamed in, then just do the
    // same as GET
    if (request.getParameter("SLD_BODY") != null) {
  doGet(request, response);
  return;
     }

     //Else do as has been done untill now.
     //With complete <GetMap> streaming, or
     //partially get and post. Some get parameters and a streamed
     //<StyledLayerDescriptor> without the <GetMap> part.
}

I am not 100% sure why there is support for streaming the body directly
in, and not add them as parameters. Maybe there are some good reasons
for it?
"My" kind of post can be done both in a browser and from java code, and
it would allow you to have just one implementation for the GetMap request.

I just redirect to the doGet() method when SLD_BODY is on the url as a
parameter. Maybe there should be smarter checks? I would love to get
some input on this, if this implementation is interesting for the project.
Maybe check if all needed parameters is present, if not allow stream?

Magne

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDad6oDjwfc5lfNZcRAjCDAJwN0YZee2BWtBlrAzri+s0xNlts4gCfXjA5
Mwr3EBzCgl+RU6QnzzjqIyk=
=6FjN
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Rasmus_Lindberg · November 3, 2005, 8:04am

Hallo

Now I'm on my way through the SLD-specification and trying to simplify and
explain how the different parts of the SLD-file works. I belive that if I
describe each part, it will be easier to understand the whole file.

How NamedLayer works is kind of basic, but now I'm trying to describe
UserLayer and I can't realy catch the point of it. I understand that it
someway refer to an outside-SLD-file, but why and how?

Can somebody explain it?

Then I promise that I will give you a Wiki-page with my result so that you
all can get an easy way to understand SLD

/ Rasmus

Brent_Owens1 · November 3, 2005, 9:24am

Hi Rasmus

We are really looking for someone to give an introduction to SLD on the GeoServer site. I have created a wiki page for you if you would like to add your thoughts to the topic: http://docs.codehaus.org/display/GEOSDOC/SLD+Introduction

Feel free to put whatever you want on it.

Brent Owens
TOPP

Rasmus Lindberg wrote:

Hallo

Now I'm on my way through the SLD-specification and trying to simplify and
explain how the different parts of the SLD-file works. I belive that if I
describe each part, it will be easier to understand the whole file.

How NamedLayer works is kind of basic, but now I'm trying to describe
UserLayer and I can't realy catch the point of it. I understand that it
someway refer to an outside-SLD-file, but why and how?

Can somebody explain it?

Then I promise that I will give you a Wiki-page with my result so that you
all can get an easy way to understand SLD

/ Rasmus

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Magne_Skjeret · November 3, 2005, 9:47am

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as GET.

Magne

The code to handle this properly does exist in the TestWfsServlet,
accessible from the demo page.

If not, I dont think it will be too hard to handle both. I am going to
make a jira task for this issue.

http://jira.codehaus.org/browse/GEOS-441

It seems you have put some time in investigating this issue. Would you
be interested in helping fix it, you could submit a patch if you were so
inclinded.

-Justin

Magne Skjeret wrote:

Hi

I have a question regarding the use of post vs. get in a GetMap request.

I have set up a test in my browser:

<form action="http://127.0.0.1/geoserver/wms" method="get">
        <input type="text" name="bbox" value="-130,24,-66,50"/>
        <input type="text" name="Format" value="image/png"/>
        <input type="text" name="request" value="GetMap"/>
        <input type="text" name="width" value="550"/>
        <input type="text" name="height" value="250"/>
        <input type="text" name="srs" value="EPSG:4326"/>
        <input type="text" name="styles" value="normal"/>
        <input type="text" name="layers" value="topp:states"/>
        <input type="submit" value="Get Map"/>
</form>

This will give a image, while changing the "method" to "post" will not.

The doPost() method is in the GetMap servlet, while the doGet() is in
the abstract service.

The doPost() method access the input stream reader directly, and read
the body as a sequence of characters (getReader()). This is fine when
you do a url connect to http://127.0.0.1/geoserver/wms and stream the
<GetMap>/<StyledLayerDescriptor> xml directly in.

But there is no real reason why a POST with paramters should act as a
GET, as long as everything is paramterized.

e.g.

public void doPost(HttpServletRequest request, HttpServletResponse
response) {
    //If the SLD is in a paramter, and not streamed in, then just do the
    // same as GET
    if (request.getParameter("SLD_BODY") != null) {
    doGet(request, response);
    return;
     }

     //Else do as has been done untill now.
     //With complete <GetMap> streaming, or
     //partially get and post. Some get parameters and a streamed
     //<StyledLayerDescriptor> without the <GetMap> part.
}

I am not 100% sure why there is support for streaming the body directly
in, and not add them as parameters. Maybe there are some good reasons
for it?
"My" kind of post can be done both in a browser and from java code, and
it would allow you to have just one implementation for the GetMap
request.

I just redirect to the doGet() method when SLD_BODY is on the url as a
parameter. Maybe there should be smarter checks? I would love to get
some input on this, if this implementation is interesting for the
project.
Maybe check if all needed parameters is present, if not allow stream?

Magne

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

jive · November 3, 2005, 11:07am

Rasmus Lindberg wrote:

Hallo

Now I'm on my way through the SLD-specification and trying to simplify and
explain how the different parts of the SLD-file works. I belive that if I
describe each part, it will be easier to understand the whole file.

How NamedLayer works is kind of basic, but now I'm trying to describe
UserLayer and I can't realy catch the point of it. I understand that it
someway refer to an outside-SLD-file, but why and how?

It seems to be a *bad idea* from the SLD 1.1. specification. The goal is to allow you to connect to an external WFS (or maybe inline GML) for the duration of a single request.

As part of the recent OWS-3 project we externalized this idea into an separate service (called Feature Portrayal Service), the hope being that the WMS waters are not rendered murkey with hacks of this nature.

This *is* useful, but I like my services to be well defined (and standardized).

Jody

jive · November 3, 2005, 11:08am

Magne Skjeret wrote:

Justin Deoliveira wrote:


Hi Magne,

This is a known issue. And after looking into it I cant really think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as GET.

Can we just check the specification? One of the benefits of having one is that we do not have to worry about things like this

Jody

Justin_Deoliveira · November 3, 2005, 11:43am

Good point, I am going to look into what the spec says.

Jody Garnett wrote:

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as GET.

Can we just check the specification? One of the benefits of having one is that we do not have to worry about things like this

Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Rasmus_Lindberg · November 4, 2005, 1:02am

It seems to be a *bad idea* from the SLD 1.1. specification.
The goal is
to allow you to connect to an external WFS (or maybe inline
GML) for the
duration of a single request.

As part of the recent OWS-3 project we externalized this idea into an
separate service (called Feature Portrayal Service), the hope
being that
the WMS waters are not rendered murkey with hacks of this nature.

This *is* useful, but I like my services to be well defined (and
standardized).

Jody

Isn't that one of the points with SLD , that you shall be able to refer or
connect to an external SLD-file when you are rendering your map? But how
this realy shall work I can't realy understand.

And as Jody say, you want your service to be neat and nice. Is it then
possible to offer a service that is both nice and give the user ability to
change the style?

/ Rasmus, who are becoming more and more confused how this works

Magne_Skjeret · November 4, 2005, 2:02am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Deoliveira wrote:

Hi

Isnt it in fact the content type that says what happens, if there is a
stream or not?

The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.

http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.

- From what I have been reading, it should be safe to assume that if the
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.

If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.

I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>

What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.

Magne

Good point, I am going to look into what the spec says.

Jody Garnett wrote:

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as
GET.

Can we just check the specification? One of the benefits of having one
is that we do not have to worry about things like this

Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDazI9Djwfc5lfNZcRAr2nAJ0Vykd2+Qi/YB/mdPjHz0bcCQbnGACfXlr/
uCofSwRygMyHd5hBiKrFl/w=
=A82C
-----END PGP SIGNATURE-----

Justin_Deoliveira · November 4, 2005, 9:29am

Hi Magne,

Thanks for doing the research on this. It looks like you are correct, there is enough information available in the request header to handle the request properly. I am attaching this conversation to the jira issue.

Any chance you would be interested in the patch. If you are worried about breaking things we can set you up with a cite test suite. Cite tests are run when releasing geoserver. They serve as great safety net.

If not, this issue will be addressed for the 1.3.0 version. Thanks.

Justin

Magne Skjeret wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Deoliveira wrote:

Hi

Isnt it in fact the content type that says what happens, if there is a
stream or not?

The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.

http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.

- From what I have been reading, it should be safe to assume that if the
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.

If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.

I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>

What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.

Magne

Good point, I am going to look into what the spec says.

Jody Garnett wrote:

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as
GET.

Can we just check the specification? One of the benefits of having one
is that we do not have to worry about things like this

Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDazI9Djwfc5lfNZcRAr2nAJ0Vykd2+Qi/YB/mdPjHz0bcCQbnGACfXlr/
uCofSwRygMyHd5hBiKrFl/w=
=A82C
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

jive · November 4, 2005, 9:49am

Rasmus Lindberg wrote:

It seems to be a *bad idea* from the SLD 1.1. specification. The goal is to allow you to connect to an external WFS (or maybe inline GML) for the duration of a single request.

As part of the recent OWS-3 project we externalized this idea into an separate service (called Feature Portrayal Service), the hope being that the WMS waters are not rendered murkey with hacks of this nature.

This *is* useful, but I like my services to be well defined (and standardized).

Jody

Isn't that one of the points with SLD , that you shall be able to refer or
connect to an external SLD-file when you are rendering your map? But how
this realy shall work I can't realy understand.

Other way around - SLD_BODY lets you sepecify an SLD file (you can do so inline or using a link to a SLD file published somewhere else).

The user layer construct is used to define new sources of data at request time ...

And as Jody say, you want your service to be neat and nice. Is it then
possible to offer a service that is both nice and give the user ability to
change the style?

To repeat WMS will let you change the style, the part I don't like is WMS being told to find new WFS information to draw from ...

/ Rasmus, who are becoming more and more confused how this works

Sorry about the confusion, does the breakdown above help? Let me try again...

WMS publishes "layers"
- you can request using GetMap with no style information
- you can request with a "named" style that the WMS provides a selection of

SLD 1.0 - defines some additional hacks for WMS
- you can request with your own custom style (SLD_BODY or a link)
- defines the SLD document

SLD 1.1 - not published, delayed 3 years
- defines userLayer allowing you to have your GetMap request fetch data from a WFS and style it with an SLD document
- userLayer allows for inline GML (which you can then style with your SLD document)
- improves the SLD document in a few ways

Cheers,
Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: Best Open Source Mac Software 2024
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Magne_Skjeret · November 4, 2005, 12:57pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Deoliveira wrote:

Hi Magne,

Hi

Yes, I am more certain now that it is a good and safe solution.
As long as we stick with the specification we should be on the safe side.

I have already create the code for this of course, but it is at work.
I will however upload it first thing Monday morning.
I am now able to do post and get forms from a html page, and also from
java code in my servlet. The TestWfsPost wrapper still works from the
request demo pages so I am pretty confident that I haven't broke
anything. I will do some more testing on Monday, but a unit test for
this would be great. Unit testing is a good way of doing software
development.

I have also create a JIRA task for the GetMapKvpReader which has a bug
in it that made non-ascii stream fail.
http://jira.codehaus.org/browse/GEOS-440
I uploaded a fix for that there.

I need to be able to use utf-8 in the sld, due to some Norwegian
letters. I probably need to add Russian labels later on, but I am not
sure about that yet. This is why I keep going on about utf-8 and
encoding. I hope I don't bore you guys.
But this is the last issue with encoding that I have found. And my
system now works perfectly.

I use this in a bit different approach that gis directly, where the
values, if any, is in the map itself.
This is a spatial system that gets data from a OLAP system and display
spatial data using colours on the map. We use the SLD to colour polygons
and set labels. It is because of the labels I need proper utf-8 support.

We are moving from a geotools1 applet implementation, to use a proper
wms implementation. We are pretty excited about the geoserver. It is a
great piece of software.

Magne

Thanks for doing the research on this. It looks like you are correct,
there is enough information available in the request header to handle
the request properly. I am attaching this conversation to the jira issue.

Any chance you would be interested in the patch. If you are worried
about breaking things we can set you up with a cite test suite. Cite
tests are run when releasing geoserver. They serve as great safety net.

If not, this issue will be addressed for the 1.3.0 version. Thanks.

Justin

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi

Isnt it in fact the content type that says what happens, if there is a
stream or not?

The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.

http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.

- From what I have been reading, it should be safe to assume that if the
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.

If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.

I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>

What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.

Magne

Good point, I am going to look into what the spec says.

Jody Garnett wrote:

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really
think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even
worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as
GET.

Can we just check the specification? One of the benefits of having one
is that we do not have to worry about things like this

Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

- -------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDa8rNDjwfc5lfNZcRAr2jAKCaCbe7Hp07d/RUnfR41JD8C/tqTACgsGI6
2C/z5+EZonkj1dcOUJStdJY=
=ZX7I
-----END PGP SIGNATURE-----

Justin_Deoliveira · November 4, 2005, 1:31pm

Hi Magne,

This is great, thanks alot for the work. I will see your patches get applied as soon as possible.

Magne Skjeret wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Deoliveira wrote:

Hi Magne,

Hi

Yes, I am more certain now that it is a good and safe solution.
As long as we stick with the specification we should be on the safe side.

I have already create the code for this of course, but it is at work.
I will however upload it first thing Monday morning.
I am now able to do post and get forms from a html page, and also from
java code in my servlet. The TestWfsPost wrapper still works from the
request demo pages so I am pretty confident that I haven't broke
anything. I will do some more testing on Monday, but a unit test for
this would be great. Unit testing is a good way of doing software
development.

Sure, submit the patch on Monday and I will have a look at it.

I have also create a JIRA task for the GetMapKvpReader which has a bug
in it that made non-ascii stream fail.
http://jira.codehaus.org/browse/GEOS-440
I uploaded a fix for that there.

Great, I will see that this patch gets tagged for our next release.

I need to be able to use utf-8 in the sld, due to some Norwegian
letters. I probably need to add Russian labels later on, but I am not
sure about that yet. This is why I keep going on about utf-8 and
encoding. I hope I don't bore you guys.
But this is the last issue with encoding that I have found. And my
system now works perfectly.

I use this in a bit different approach that gis directly, where the
values, if any, is in the map itself.
This is a spatial system that gets data from a OLAP system and display
spatial data using colours on the map. We use the SLD to colour polygons
and set labels. It is because of the labels I need proper utf-8 support.

We are moving from a geotools1 applet implementation, to use a proper
wms implementation. We are pretty excited about the geoserver. It is a
great piece of software.

Magne

Thanks for doing the research on this. It looks like you are correct,
there is enough information available in the request header to handle
the request properly. I am attaching this conversation to the jira issue.

Any chance you would be interested in the patch. If you are worried
about breaking things we can set you up with a cite test suite. Cite
tests are run when releasing geoserver. They serve as great safety net.

If not, this issue will be addressed for the 1.3.0 version. Thanks.

Justin

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi

Isnt it in fact the content type that says what happens, if there is a
stream or not?

The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.

http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.

- From what I have been reading, it should be safe to assume that if the
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.

If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.

I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>

What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.

Magne

Good point, I am going to look into what the spec says.

Jody Garnett wrote:

Magne Skjeret wrote:

Justin Deoliveira wrote:

Hi Magne,

This is a known issue. And after looking into it I cant really
think of
a reason why post has to be directly streamed in. However one of the
other developers may have a reason.

Hi Justin

This is one of my fears, that I break some existing code, or even
worse
break some of the projects that use geoserver.
I just made the assumption that if SLD_BODY is on the url, then there
will be no sld streamed directly in.

I wonder if it would possible to check the stream if there is content,
before moving to doGet() instead if there is content in
request.getParameter(). I need to investigate that further.

Is there a example section? I can provide some example code how to use
POST directly from your java code, making it possible to use POST as
GET.

Can we just check the specification? One of the benefits of having one
is that we do not have to worry about things like this

Jody

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

- -------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDa8rNDjwfc5lfNZcRAr2jAKCaCbe7Hp07d/RUnfR41JD8C/tqTACgsGI6
2C/z5+EZonkj1dcOUJStdJY=
=ZX7I
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Rasmus_Lindberg · November 7, 2005, 6:48am

One thing I have been thinking alot about lately is that there are severel
levels in SLD befor you reach the Symbolizers. Can somebody explain the
point of NamedLayer->NamedStyle->FeatureTypeStyle->Rule.

And in each of this levels you are able to have Name, Title, Abstract. Has
anybody of you experience of using these in all levels? Will there be a GUI
where you will be able to choose which Named or UserLeyer to use, and which
Named or UserStyle to use, and which FeatureTypeStyle to use, and which Rule
to use..... Or will we keep it much simplier? If, what use are there for the
Name, Title and Abstract at each level?

Maybee these questeions are better to ask them how are responsible for the
SLD-spec, but who is that?

/ Rasmus

jive · November 7, 2005, 11:21am

Rasmus Lindberg wrote:

One thing I have been thinking alot about lately is that there are severel
levels in SLD befor you reach the Symbolizers. Can somebody explain the
point of NamedLayer->NamedStyle->FeatureTypeStyle->Rule.

Have you read the specification? (Or are you thinking straight about the Geotools objects?)
NamedLayer - indicates we are using a WMS named layer (as oppsed to a UserLayer that may referecen inline GML or an external WFS)
NamedStyle - indicates we are using a Named Style? This is kind of the start of style information, may containing styling for several different feature types
FeatureTypeStyle - indicates which feature type is being styled, note this pays attention to the parent/child relationship between FeatureTypes (so "Feature" is the root of all FeatureTypes)
Rule - provides a filter that defines which subset of all the feature types of type indicated in FeatureTypeStyle should be drawn, each rule is basically rendered one after the other
Symbolizer - specfic mapping between content (FeatureType, Coverage, etc...) and portrayal instructions

And in each of this levels you are able to have Name, Title, Abstract. Has
anybody of you experience of using these in all levels? Will there be a GUI
where you will be able to choose which Named or UserLeyer to use, and which
Named or UserStyle to use, and which FeatureTypeStyle to use, and which Rule
to use..... Or will we keep it much simplier? If, what use are there for the
Name, Title and Abstract at each level?

Tracking What is the use for metadata in general? You may be mixing these elements up in different SLD documents... or assembling them from different sources.

Maybee these questeions are better to ask them how are responsible for the
SLD-spec, but who is that?

The SLD Revision Working Group, James Macgill (the geotools interpid leader) is a member. I have played a small part recently in taking FeatureType style to its own document (called Symbology Encoding Document). Aka only the stuff that can be resued...

Jody

Bryce_L_Nordgren · November 7, 2005, 2:24pm

geoserver-devel-admin@lists.sourceforge.net wrote on 11/07/2005 12:21:23
PM:

The SLD Revision Working Group, James Macgill (the geotools interpid
leader) is a member. I have played a small part recently in taking
FeatureType style to its own document (called Symbology Encoding
Document). Aka only the stuff that can be resued...

Here's a question I have for forward-thinking individuals: Are the
next-generation documents being written up as profiles of ISO19117? If SLD
was an implementation of 19117, you'd have a predefined, standard
"portrayal catalog" plus you have a predefined extension mechanism built in
(e.g., people who want to do wind barbs would make their own portrayal
catalog.) It would be easier to write a "community extension" to the
standard if the standard itself was just a default catalog built on the
existing framework.

Bryce

jive · November 7, 2005, 2:31pm

Bryce L Nordgren wrote:

geoserver-devel-admin@lists.sourceforge.net wrote on 11/07/2005 12:21:23
PM:


The SLD Revision Working Group, James Macgill (the geotools interpid
leader) is a member. I have played a small part recently in taking
FeatureType style to its own document (called Symbology Encoding
Document). Aka only the stuff that can be resued...


Here's a question I have for forward-thinking individuals: Are the
next-generation documents being written up as profiles of ISO19117? If SLD
was an implementation of 19117, you'd have a predefined, standard
"portrayal catalog" plus you have a predefined extension mechanism built in
(e.g., people who want to do wind barbs would make their own portrayal
catalog.) It would be easier to write a "community extension" to the
standard if the standard itself was just a default catalog built on the
existing framework.

I am not sure if there is much communication between the two groups at the moment,
I think the OGC types expect you to place your SLD documents in a catalog and herd
it along like normal data (aka an intrinsic object).

To be explicit the definition of a portrayal catalog is not explicit, portrayal is focused on
exclusively and the construction of a catalog (aka an infrastructure) is left an an exercise
to the reader (or at least the reader waiting for a useful ebRIM profile to appear).

We did make use of a catalog in this manner as part of the OWS-3 project, if you download
our client document you will be able to find sample XML requests/responses and sequence diagrams
that go into these ideas in more detail.

I am afraid the document is still in draft form, and will await the pleasure of a technical meeting review
before being available for wider download.

Jody