[Geoserver-devel] Re: SLD-POST no longer working

There seems to be a problem with the patch that was supplied for http://jira.codehaus.org/browse/GEOS-441. The patch fixes handling form based requests, however seems to have caused another problem (see below).

Justin

Justin Deoliveira wrote:

On 11/29/05, *David Blasby* <dblasby@anonymised.com <mailto:dblasby@anonymised.com>> wrote:

    Justin,

    You've taken out the entire SLD-POST system!

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

    Your assumptions are incorrect.

    For example, AJAX XMLRequestObject sets the content type as:
    Content-Type: text/xml

    NOTE: The test post form servlet miss-labels the content-type as
    "application/x-www-form-urlencoded". (it doesnt change the
    content-type)

    You'll get an error because the POST system is just handing it off to
    the GET system.

             if (!isMultipartContent(request)) {
                   doGet(request, response);
                   return;
                }

    The system is now taking a perfectly valid XML POST and handing it off
    to the Get System - this has no chance of working.

    The GET system assumes that all the info is in parameters (get or
    post), but the XML version reads them from the included XML document
    (see the attached example - there's <Width> tags etc...).

    There were two types of SLD-POST:
    * there's the full XML (as per the attached example). The XML is
    just in the request body and the XML root its "<GetMap>".
    * a partial XML where you put most of the parameters in the URL and
    then stick the SLD_BODY in the POST portion
    GetMapXMLReader#handlePostGet(). The XML is just in the request body
    and the XML root is "<StyledLayerDescriptor>".

    If you really dont like the 2nd way, you can remove it, but it was
    requested because its a happy medium for people who dont like really
    long URLs (and weird URL encoding problems when you used colours
    ("#...") in your SLD) when you use SLD_BODY.
    NOTE - <IMG> tags do not support POST so SLD-POST is a bit difficult
    to actually use (way to go, OGC). I very recently re-started the
    indirect post-get discussion.

    To reproduce (any configuration will work since all the data is in
    inlinefeatures in the SLD - nifty,eh):

    1. go to the testpost form demo->Sample Requests
    2. choose any WFS request and hit change
    3. change the url to http://localhost:8080/geoserver/wms
    4. copy and paste in the attached xml
    5. hit submit
    6. You used to get a smiling face picture back, now you get an error.

    If you remove the java lines from above, everything seems to go back
    to working.

    I think if you:
    1. change the testpost system so its a bit smarter with the new
    request's content-type
    2. make GetMap wiser about what to do based on the content-type and if
    its POST. You probably want to specifically pass-off to GET for a set
    of HTML-form content-types and default to POST for all others. At
    least make sure that text/xml get passed off to the POST system.
    3. remove the 1/2 Get - 1/2 Post system.

    you'll find everything works.

    Please - test test test.

    dave

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

Justin Deoliveira wrote:

There seems to be a problem with the patch that was supplied for
http://jira.codehaus.org/browse/GEOS-441. The patch fixes handling form
based requests, however seems to have caused another problem (see below).

Hi

I seems that I have made the assumption that if it was not multipart,
then it was url encoded. This assumption does not hold.

I have changed the code so that it forwards to get when it is
application/x-www-form-urlencoded, not else.

So content types like application/xml (or any other) will get through to
the post system.

This is however not enough to fix this issue.
The real bad piece of code is actually in TestWfsPost.
I must admit I do not understand the purpose of this servlet.
First of all it is called something with test and it is called something
with Wfs, but still used for Wms requests too.
I don't get why it needs to be there, as it can be handled in the
different service servlets itself (the form on the sample page would
need to change though).

The problem with the TestWfsPost is the following:

The sample form is submitted correctly with the content type of
application/x-www-form-urlencoded. There are two parameters included.
request.getParameter("url")
request.getParameter("body")

Both of the above methods will give the correct result in TestWfsPost.

But then TestWfsPost connects to the url given, and stream the body
parameter.
The problem is that the content type is then not set, and the default
url encode content type is used. That is the incorrect mime-type. The
connection to the url given is not with url encode, but should be with
application/xml. Since the content type say it is a url encoded request,
the GetMap servlet will forward you (correctly I would dare to say) to
get GET handler.

If the TestWfsPost however gives the correct content type of the
forwarded request, application/xml, it all works fine.

I have done the implementation for this now, and it seems to be working
correctly. If there is data in the body parameter from the form, the
content type is changed to application/xml, else the
x-www-form-urlencoded is kept.
I have however not have a complete sld xml to test, but all entries in
the sample request now works again. So the mix url parameters and xml
stream is working.

I have not commited yet, to give you a chance to comment on this mail
before I do anything.

If someone has a complete sld xml that I can test with the default
layers added in the geoserver, I will be happy to do a test.

Magne

Justin

Justin Deoliveira wrote:

On 11/29/05, *David Blasby* <dblasby@anonymised.com
<mailto:dblasby@anonymised.com>> wrote:

    Justin,

    You've taken out the entire SLD-POST system!

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

    Your assumptions are incorrect.

    For example, AJAX XMLRequestObject sets the content type as:
    Content-Type: text/xml

    NOTE: The test post form servlet miss-labels the content-type as
    "application/x-www-form-urlencoded". (it doesnt change the
    content-type)

    You'll get an error because the POST system is just handing it off to
    the GET system.

             if (!isMultipartContent(request)) {
                   doGet(request, response);
                   return;
                }

    The system is now taking a perfectly valid XML POST and handing it
off
    to the Get System - this has no chance of working.

    The GET system assumes that all the info is in parameters (get or
    post), but the XML version reads them from the included XML document
    (see the attached example - there's <Width> tags etc...).

    There were two types of SLD-POST:
    * there's the full XML (as per the attached example). The XML is
    just in the request body and the XML root its "<GetMap>".
    * a partial XML where you put most of the parameters in the URL and
    then stick the SLD_BODY in the POST portion
    GetMapXMLReader#handlePostGet(). The XML is just in the request body
    and the XML root is "<StyledLayerDescriptor>".

    If you really dont like the 2nd way, you can remove it, but it was
    requested because its a happy medium for people who dont like really
    long URLs (and weird URL encoding problems when you used colours
    ("#...") in your SLD) when you use SLD_BODY.
    NOTE - <IMG> tags do not support POST so SLD-POST is a bit difficult
    to actually use (way to go, OGC). I very recently re-started the
    indirect post-get discussion.

    To reproduce (any configuration will work since all the data is in
    inlinefeatures in the SLD - nifty,eh):

    1. go to the testpost form demo->Sample Requests
    2. choose any WFS request and hit change
    3. change the url to http://localhost:8080/geoserver/wms
    4. copy and paste in the attached xml
    5. hit submit
    6. You used to get a smiling face picture back, now you get an error.

    If you remove the java lines from above, everything seems to go back
    to working.

    I think if you:
    1. change the testpost system so its a bit smarter with the new
    request's content-type
    2. make GetMap wiser about what to do based on the content-type
and if
    its POST. You probably want to specifically pass-off to GET for a
set
    of HTML-form content-types and default to POST for all others. At
    least make sure that text/xml get passed off to the POST system.
    3. remove the 1/2 Get - 1/2 Post system.

    you'll find everything works.

    Please - test test test.

    dave

Hi Magne,

Thanks for the quick response. Hopefully dave can have a look at your fix and comment.

Justin

Magne Skjeret wrote:

Justin Deoliveira wrote:

There seems to be a problem with the patch that was supplied for
http://jira.codehaus.org/browse/GEOS-441. The patch fixes handling form
based requests, however seems to have caused another problem (see below).

Hi

I seems that I have made the assumption that if it was not multipart,
then it was url encoded. This assumption does not hold.

I have changed the code so that it forwards to get when it is
application/x-www-form-urlencoded, not else.

So content types like application/xml (or any other) will get through to
the post system.

This is however not enough to fix this issue.
The real bad piece of code is actually in TestWfsPost.
I must admit I do not understand the purpose of this servlet.
First of all it is called something with test and it is called something
with Wfs, but still used for Wms requests too.
I don't get why it needs to be there, as it can be handled in the
different service servlets itself (the form on the sample page would
need to change though).

The problem with the TestWfsPost is the following:

The sample form is submitted correctly with the content type of
application/x-www-form-urlencoded. There are two parameters included.
request.getParameter("url")
request.getParameter("body")

Both of the above methods will give the correct result in TestWfsPost.

But then TestWfsPost connects to the url given, and stream the body
parameter.
The problem is that the content type is then not set, and the default
url encode content type is used. That is the incorrect mime-type. The
connection to the url given is not with url encode, but should be with
application/xml. Since the content type say it is a url encoded request,
the GetMap servlet will forward you (correctly I would dare to say) to
get GET handler.

If the TestWfsPost however gives the correct content type of the
forwarded request, application/xml, it all works fine.

I have done the implementation for this now, and it seems to be working
correctly. If there is data in the body parameter from the form, the
content type is changed to application/xml, else the
x-www-form-urlencoded is kept.
I have however not have a complete sld xml to test, but all entries in
the sample request now works again. So the mix url parameters and xml
stream is working.

I have not commited yet, to give you a chance to comment on this mail
before I do anything.

If someone has a complete sld xml that I can test with the default
layers added in the geoserver, I will be happy to do a test.

Magne

Justin

Justin Deoliveira wrote:

On 11/29/05, *David Blasby* <dblasby@anonymised.com
<mailto:dblasby@anonymised.com>> wrote:

   Justin,

   You've taken out the entire SLD-POST system!

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

   Your assumptions are incorrect.

   For example, AJAX XMLRequestObject sets the content type as:
   Content-Type: text/xml

   NOTE: The test post form servlet miss-labels the content-type as
   "application/x-www-form-urlencoded". (it doesnt change the
   content-type)

   You'll get an error because the POST system is just handing it off to
   the GET system.

            if (!isMultipartContent(request)) {
                  doGet(request, response);
                  return;
               }

   The system is now taking a perfectly valid XML POST and handing it
off
   to the Get System - this has no chance of working.

   The GET system assumes that all the info is in parameters (get or
   post), but the XML version reads them from the included XML document
   (see the attached example - there's <Width> tags etc...).

   There were two types of SLD-POST:
   * there's the full XML (as per the attached example). The XML is
   just in the request body and the XML root its "<GetMap>".
   * a partial XML where you put most of the parameters in the URL and
   then stick the SLD_BODY in the POST portion
   GetMapXMLReader#handlePostGet(). The XML is just in the request body
   and the XML root is "<StyledLayerDescriptor>".

   If you really dont like the 2nd way, you can remove it, but it was
   requested because its a happy medium for people who dont like really
   long URLs (and weird URL encoding problems when you used colours
   ("#...") in your SLD) when you use SLD_BODY.
   NOTE - <IMG> tags do not support POST so SLD-POST is a bit difficult
   to actually use (way to go, OGC). I very recently re-started the
   indirect post-get discussion.

   To reproduce (any configuration will work since all the data is in
   inlinefeatures in the SLD - nifty,eh):

   1. go to the testpost form demo->Sample Requests
   2. choose any WFS request and hit change
   3. change the url to http://localhost:8080/geoserver/wms
   4. copy and paste in the attached xml
   5. hit submit
   6. You used to get a smiling face picture back, now you get an error.

   If you remove the java lines from above, everything seems to go back
   to working.

   I think if you:
   1. change the testpost system so its a bit smarter with the new
   request's content-type
   2. make GetMap wiser about what to do based on the content-type
and if
   its POST. You probably want to specifically pass-off to GET for a
set
   of HTML-form content-types and default to POST for all others. At
   least make sure that text/xml get passed off to the POST system.
   3. remove the 1/2 Get - 1/2 Post system.

   you'll find everything works.

   Please - test test test.

   dave

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

Hi Magne,

Go ahead and commit your change. Let me know when you do so and I will help test to make sure the issue is resolved.

Justin

Justin Deoliveira wrote:

Hi Magne,

Thanks for the quick response. Hopefully dave can have a look at your fix and comment.

Justin

Magne Skjeret wrote:

Justin Deoliveira wrote:

There seems to be a problem with the patch that was supplied for
http://jira.codehaus.org/browse/GEOS-441. The patch fixes handling form
based requests, however seems to have caused another problem (see below).

Hi

I seems that I have made the assumption that if it was not multipart,
then it was url encoded. This assumption does not hold.

I have changed the code so that it forwards to get when it is
application/x-www-form-urlencoded, not else.

So content types like application/xml (or any other) will get through to
the post system.

This is however not enough to fix this issue.
The real bad piece of code is actually in TestWfsPost.
I must admit I do not understand the purpose of this servlet.
First of all it is called something with test and it is called something
with Wfs, but still used for Wms requests too.
I don't get why it needs to be there, as it can be handled in the
different service servlets itself (the form on the sample page would
need to change though).

The problem with the TestWfsPost is the following:

The sample form is submitted correctly with the content type of
application/x-www-form-urlencoded. There are two parameters included.
request.getParameter("url")
request.getParameter("body")

Both of the above methods will give the correct result in TestWfsPost.

But then TestWfsPost connects to the url given, and stream the body
parameter.
The problem is that the content type is then not set, and the default
url encode content type is used. That is the incorrect mime-type. The
connection to the url given is not with url encode, but should be with
application/xml. Since the content type say it is a url encoded request,
the GetMap servlet will forward you (correctly I would dare to say) to
get GET handler.

If the TestWfsPost however gives the correct content type of the
forwarded request, application/xml, it all works fine.

I have done the implementation for this now, and it seems to be working
correctly. If there is data in the body parameter from the form, the
content type is changed to application/xml, else the
x-www-form-urlencoded is kept.
I have however not have a complete sld xml to test, but all entries in
the sample request now works again. So the mix url parameters and xml
stream is working.

I have not commited yet, to give you a chance to comment on this mail
before I do anything.

If someone has a complete sld xml that I can test with the default
layers added in the geoserver, I will be happy to do a test.

Magne

Justin

Justin Deoliveira wrote:

On 11/29/05, *David Blasby* <dblasby@anonymised.com
<mailto:dblasby@anonymised.com>> wrote:

   Justin,

   You've taken out the entire SLD-POST system!

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

   Your assumptions are incorrect.

   For example, AJAX XMLRequestObject sets the content type as:
   Content-Type: text/xml

   NOTE: The test post form servlet miss-labels the content-type as
   "application/x-www-form-urlencoded". (it doesnt change the
   content-type)

   You'll get an error because the POST system is just handing it off to
   the GET system.

            if (!isMultipartContent(request)) {
                  doGet(request, response);
                  return;
               }

   The system is now taking a perfectly valid XML POST and handing it
off
   to the Get System - this has no chance of working.

   The GET system assumes that all the info is in parameters (get or
   post), but the XML version reads them from the included XML document
   (see the attached example - there's <Width> tags etc...).

   There were two types of SLD-POST:
   * there's the full XML (as per the attached example). The XML is
   just in the request body and the XML root its "<GetMap>".
   * a partial XML where you put most of the parameters in the URL and
   then stick the SLD_BODY in the POST portion
   GetMapXMLReader#handlePostGet(). The XML is just in the request body
   and the XML root is "<StyledLayerDescriptor>".

   If you really dont like the 2nd way, you can remove it, but it was
   requested because its a happy medium for people who dont like really
   long URLs (and weird URL encoding problems when you used colours
   ("#...") in your SLD) when you use SLD_BODY.
   NOTE - <IMG> tags do not support POST so SLD-POST is a bit difficult
   to actually use (way to go, OGC). I very recently re-started the
   indirect post-get discussion.

   To reproduce (any configuration will work since all the data is in
   inlinefeatures in the SLD - nifty,eh):

   1. go to the testpost form demo->Sample Requests
   2. choose any WFS request and hit change
   3. change the url to http://localhost:8080/geoserver/wms
   4. copy and paste in the attached xml
   5. hit submit
   6. You used to get a smiling face picture back, now you get an error.

   If you remove the java lines from above, everything seems to go back
   to working.

   I think if you:
   1. change the testpost system so its a bit smarter with the new
   request's content-type
   2. make GetMap wiser about what to do based on the content-type
and if
   its POST. You probably want to specifically pass-off to GET for a
set
   of HTML-form content-types and default to POST for all others. At
   least make sure that text/xml get passed off to the POST system.
   3. remove the 1/2 Get - 1/2 Post system.

   you'll find everything works.

   Please - test test test.

   dave

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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

Justin Deoliveira wrote:

Hi Magne,

Go ahead and commit your change. Let me know when you do so and I will
help test to make sure the issue is resolved.

Hi

Code is in.
Of to work.

Magne

Justin

Justin Deoliveira wrote:

Hi Magne,

Thanks for the quick response. Hopefully dave can have a look at your
fix and comment.

Justin

Magne Skjeret wrote:

Justin Deoliveira wrote:

There seems to be a problem with the patch that was supplied for
http://jira.codehaus.org/browse/GEOS-441. The patch fixes handling form
based requests, however seems to have caused another problem (see
below).

Hi

I seems that I have made the assumption that if it was not multipart,
then it was url encoded. This assumption does not hold.

I have changed the code so that it forwards to get when it is
application/x-www-form-urlencoded, not else.

So content types like application/xml (or any other) will get through to
the post system.

This is however not enough to fix this issue.
The real bad piece of code is actually in TestWfsPost.
I must admit I do not understand the purpose of this servlet.
First of all it is called something with test and it is called something
with Wfs, but still used for Wms requests too.
I don't get why it needs to be there, as it can be handled in the
different service servlets itself (the form on the sample page would
need to change though).

The problem with the TestWfsPost is the following:

The sample form is submitted correctly with the content type of
application/x-www-form-urlencoded. There are two parameters included.
request.getParameter("url")
request.getParameter("body")

Both of the above methods will give the correct result in TestWfsPost.

But then TestWfsPost connects to the url given, and stream the body
parameter.
The problem is that the content type is then not set, and the default
url encode content type is used. That is the incorrect mime-type. The
connection to the url given is not with url encode, but should be with
application/xml. Since the content type say it is a url encoded request,
the GetMap servlet will forward you (correctly I would dare to say) to
get GET handler.

If the TestWfsPost however gives the correct content type of the
forwarded request, application/xml, it all works fine.

I have done the implementation for this now, and it seems to be working
correctly. If there is data in the body parameter from the form, the
content type is changed to application/xml, else the
x-www-form-urlencoded is kept.
I have however not have a complete sld xml to test, but all entries in
the sample request now works again. So the mix url parameters and xml
stream is working.

I have not commited yet, to give you a chance to comment on this mail
before I do anything.

If someone has a complete sld xml that I can test with the default
layers added in the geoserver, I will be happy to do a test.

Magne

Justin

Justin Deoliveira wrote:

On 11/29/05, *David Blasby* <dblasby@anonymised.com
<mailto:dblasby@anonymised.com>> wrote:

   Justin,

   You've taken out the entire SLD-POST system!

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

   Your assumptions are incorrect.

   For example, AJAX XMLRequestObject sets the content type as:
   Content-Type: text/xml

   NOTE: The test post form servlet miss-labels the content-type as
   "application/x-www-form-urlencoded". (it doesnt change the
   content-type)

   You'll get an error because the POST system is just handing it
off to
   the GET system.

            if (!isMultipartContent(request)) {
                  doGet(request, response);
                  return;
               }

   The system is now taking a perfectly valid XML POST and handing it
off
   to the Get System - this has no chance of working.

   The GET system assumes that all the info is in parameters (get or
   post), but the XML version reads them from the included XML
document
   (see the attached example - there's <Width> tags etc...).

   There were two types of SLD-POST:
   * there's the full XML (as per the attached example). The XML is
   just in the request body and the XML root its "<GetMap>".
   * a partial XML where you put most of the parameters in the URL and
   then stick the SLD_BODY in the POST portion
   GetMapXMLReader#handlePostGet(). The XML is just in the request
body
   and the XML root is "<StyledLayerDescriptor>".

   If you really dont like the 2nd way, you can remove it, but it was
   requested because its a happy medium for people who dont like
really
   long URLs (and weird URL encoding problems when you used colours
   ("#...") in your SLD) when you use SLD_BODY.
   NOTE - <IMG> tags do not support POST so SLD-POST is a bit
difficult
   to actually use (way to go, OGC). I very recently re-started the
   indirect post-get discussion.

   To reproduce (any configuration will work since all the data is in
   inlinefeatures in the SLD - nifty,eh):

   1. go to the testpost form demo->Sample Requests
   2. choose any WFS request and hit change
   3. change the url to http://localhost:8080/geoserver/wms
   4. copy and paste in the attached xml
   5. hit submit
   6. You used to get a smiling face picture back, now you get an
error.

   If you remove the java lines from above, everything seems to go
back
   to working.

   I think if you:
   1. change the testpost system so its a bit smarter with the new
   request's content-type
   2. make GetMap wiser about what to do based on the content-type
and if
   its POST. You probably want to specifically pass-off to GET for a
set
   of HTML-form content-types and default to POST for all others. At
   least make sure that text/xml get passed off to the POST system.
   3. remove the 1/2 Get - 1/2 Post system.

   you'll find everything works.

   Please - test test test.

   dave

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel