Menu
▾
▴
resteasy-developers
|
From: Ron S. <rs...@re...> - 2012-10-14 05:27:27
|
Hi Remy,
I'm working on RESTEASY-760 "@FormParam does not work with PUT method
when a Query param is present", in which the reporter claims (and I've
verified the behavior), that if he sends a request with both query
parameters and form parameters, Resteasy doesn't pass the form
parameters into his JAX-RS resource. It seems that in jbossweb,
org.apache.catalina.connector.RequestFacade.getParameterMap() returns
only query parameters, despite the javadoc on
javax.servlet.ServletRequest.getParameterMap(), which says
/**
* Returns a java.util.Map of the parameters of this request.
*
* <p>Request parameters are extra information sent with the request.
* For HTTP servlets, parameters are contained in the query string or
* posted form data.
*
* @return an immutable java.util.Map containing parameter names as
* keys and parameter values as map values. The keys in the parameter
* map are of type String. The values in the parameter map are of type
* String array.
*/
1. Is this behavior a bug in jbossweb? I don't see any jbossweb
parameters that override the behavior. Granted, the javadoc is a little
ambiguous, where it says, "parameters are contained in the query string
<em>OR</em> posted form data.
2. Resteasy already has a workaround for Tomcat:
// Tomcat does not set getParameters() if it is a PUT request
// so pull it out manually
if (request.getMethod().equals("PUT") &&
(request.getParameterMap() == null || request.getParameterMap().isEmpty()))
{
return getPutFormParameters();
}
where getPutFormParameters() pulls form parameters directly from the
input stream. I'm thinking of adding this:
Map<String, String[]> parameterMap = request.getParameterMap();
MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
if (mapEquals(parameterMap, queryMap))
{
return getPutFormParameters();
}
In other words, it's a test that request.getParameterMap() contains only
query parameters.
My next question is, is this safe? Is it possible that the input stream
has already been read?
Thanks,
Ron
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Bill B. <bb...@re...> - 2012-10-15 13:19:14
|
Are you sure our stuff doesn't work? Maybe the user is consuming the
input stream somewhere.
On 10/14/2012 1:27 AM, Ron Sigal wrote:
> Hi Remy,
>
> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
> when a Query param is present", in which the reporter claims (and I've
> verified the behavior), that if he sends a request with both query
> parameters and form parameters, Resteasy doesn't pass the form
> parameters into his JAX-RS resource. It seems that in jbossweb,
> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
> only query parameters, despite the javadoc on
> javax.servlet.ServletRequest.getParameterMap(), which says
>
> /**
> * Returns a java.util.Map of the parameters of this request.
> *
> * <p>Request parameters are extra information sent with the request.
> * For HTTP servlets, parameters are contained in the query string or
> * posted form data.
> *
> * @return an immutable java.util.Map containing parameter names as
> * keys and parameter values as map values. The keys in the parameter
> * map are of type String. The values in the parameter map are of type
> * String array.
> */
>
> 1. Is this behavior a bug in jbossweb? I don't see any jbossweb
> parameters that override the behavior. Granted, the javadoc is a little
> ambiguous, where it says, "parameters are contained in the query string
> <em>OR</em> posted form data.
>
> 2. Resteasy already has a workaround for Tomcat:
>
> // Tomcat does not set getParameters() if it is a PUT request
> // so pull it out manually
> if (request.getMethod().equals("PUT") &&
> (request.getParameterMap() == null || request.getParameterMap().isEmpty()))
> {
> return getPutFormParameters();
> }
>
> where getPutFormParameters() pulls form parameters directly from the
> input stream. I'm thinking of adding this:
>
> Map<String, String[]> parameterMap = request.getParameterMap();
> MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
> if (mapEquals(parameterMap, queryMap))
> {
> return getPutFormParameters();
> }
>
> In other words, it's a test that request.getParameterMap() contains only
> query parameters.
>
> My next question is, is this safe? Is it possible that the input stream
> has already been read?
>
> Thanks,
> Ron
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ron S. <rs...@re...> - 2012-10-15 16:08:23
|
I've replicated the problem with my own tests.
On 10/15/2012 09:19 AM, Bill Burke wrote:
> Are you sure our stuff doesn't work? Maybe the user is consuming the
> input stream somewhere.
>
> On 10/14/2012 1:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>> when a Query param is present", in which the reporter claims (and I've
>> verified the behavior), that if he sends a request with both query
>> parameters and form parameters, Resteasy doesn't pass the form
>> parameters into his JAX-RS resource. It seems that in jbossweb,
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>> only query parameters, despite the javadoc on
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>> /**
>> * Returns a java.util.Map of the parameters of this request.
>> *
>> * <p>Request parameters are extra information sent with the
>> request.
>> * For HTTP servlets, parameters are contained in the query
>> string or
>> * posted form data.
>> *
>> * @return an immutable java.util.Map containing parameter names as
>> * keys and parameter values as map values. The keys in the
>> parameter
>> * map are of type String. The values in the parameter map are
>> of type
>> * String array.
>> */
>>
>> 1. Is this behavior a bug in jbossweb? I don't see any jbossweb
>> parameters that override the behavior. Granted, the javadoc is a little
>> ambiguous, where it says, "parameters are contained in the query string
>> <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>> // Tomcat does not set getParameters() if it is a PUT request
>> // so pull it out manually
>> if (request.getMethod().equals("PUT") &&
>> (request.getParameterMap() == null ||
>> request.getParameterMap().isEmpty()))
>> {
>> return getPutFormParameters();
>> }
>>
>> where getPutFormParameters() pulls form parameters directly from the
>> input stream. I'm thinking of adding this:
>>
>> Map<String, String[]> parameterMap = request.getParameterMap();
>> MultivaluedMap<String, String> queryMap =
>> uri.getQueryParameters();
>> if (mapEquals(parameterMap, queryMap))
>> {
>> return getPutFormParameters();
>> }
>>
>> In other words, it's a test that request.getParameterMap() contains only
>> query parameters.
>>
>> My next question is, is this safe? Is it possible that the input stream
>> has already been read?
>>
>> Thanks,
>> Ron
>>
>>
>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Bill B. <bb...@re...> - 2012-10-15 13:41:18
|
Please move these types of discussions to the dev list.
But, for form processing, there's a few things you have to worry about.
1) Did a Servlet filter eat the input stream? You'll need to use
getParameterMap() then.
2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
input stream or not?
3) If its Tomcat, a PUT, and the filter ate the input stream, you're up
shit creek.
On 10/15/2012 9:36 AM, Rémy Maucherat wrote:
> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>> when a Query param is present", in which the reporter claims (and I've
>> verified the behavior), that if he sends a request with both query
>> parameters and form parameters, Resteasy doesn't pass the form
>> parameters into his JAX-RS resource. It seems that in jbossweb,
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>> only query parameters, despite the javadoc on
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>> /**
>> * Returns a java.util.Map of the parameters of this request.
>> *
>> * <p>Request parameters are extra information sent with the request.
>> * For HTTP servlets, parameters are contained in the query string or
>> * posted form data.
>> *
>> * @return an immutable java.util.Map containing parameter names as
>> * keys and parameter values as map values. The keys in the parameter
>> * map are of type String. The values in the parameter map are of
>> type
>> * String array.
>> */
>>
>> 1. Is this behavior a bug in jbossweb? I don't see any jbossweb
>> parameters that override the behavior. Granted, the javadoc is a
>> little ambiguous, where it says, "parameters are contained in the
>> query string <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>> // Tomcat does not set getParameters() if it is a PUT request
>> // so pull it out manually
>> if (request.getMethod().equals("PUT") &&
>> (request.getParameterMap() == null ||
>> request.getParameterMap().isEmpty()))
>> {
>> return getPutFormParameters();
>> }
>>
>> where getPutFormParameters() pulls form parameters directly from the
>> input stream. I'm thinking of adding this:
>>
>> Map<String, String[]> parameterMap = request.getParameterMap();
>> MultivaluedMap<String, String> queryMap = uri.getQueryParameters();
>> if (mapEquals(parameterMap, queryMap))
>> {
>> return getPutFormParameters();
>> }
>>
>> In other words, it's a test that request.getParameterMap() contains
>> only query parameters.
>>
>> My next question is, is this safe? Is it possible that the input
>> stream has already been read?
>>
> The web container only processes URL encoded POSTs, not any other method
> (as per the spec).
>
> Although it is a convenient API, it is possible that the integrated
> processing is very resource intensive compared to what is actually
> needed, with questionable scalability, since it parses everything down
> to individual strings, and puts everything in a hash map.
>
> Rémy
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ron S. <rs...@re...> - 2012-10-15 17:08:12
|
On 10/15/2012 09:40 AM, Bill Burke wrote:
> Please move these types of discussions to the dev list.
It's on the cc list. I cc'd you and Weinan, which I guess is redundant.
>
> But, for form processing, there's a few things you have to worry about.
>
> 1) Did a Servlet filter eat the input stream? You'll need to use
> getParameterMap() then.
I'm not using a filter in my own tests. But if the container doesn't
put form parameters in the parameter map, that won't work. I guess we
can put a warning in the Resteasy User Guide.
> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
> input stream or not?
I get the same results with POST and PUT. For jbossweb, my change
works for both, so jbossweb, at least, isn't eating the input stream.
> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
> up shit creek.
In that case, again, I guess all we can do is put a warning in the
Resteasy User Guide.
>
> On 10/15/2012 9:36 AM, Rémy Maucherat wrote:
>> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>>> Hi Remy,
>>>
>>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>>> when a Query param is present", in which the reporter claims (and I've
>>> verified the behavior), that if he sends a request with both query
>>> parameters and form parameters, Resteasy doesn't pass the form
>>> parameters into his JAX-RS resource. It seems that in jbossweb,
>>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>>> only query parameters, despite the javadoc on
>>> javax.servlet.ServletRequest.getParameterMap(), which says
>>>
>>> /**
>>> * Returns a java.util.Map of the parameters of this request.
>>> *
>>> * <p>Request parameters are extra information sent with the
>>> request.
>>> * For HTTP servlets, parameters are contained in the query
>>> string or
>>> * posted form data.
>>> *
>>> * @return an immutable java.util.Map containing parameter names as
>>> * keys and parameter values as map values. The keys in the
>>> parameter
>>> * map are of type String. The values in the parameter map are of
>>> type
>>> * String array.
>>> */
>>>
>>> 1. Is this behavior a bug in jbossweb? I don't see any jbossweb
>>> parameters that override the behavior. Granted, the javadoc is a
>>> little ambiguous, where it says, "parameters are contained in the
>>> query string <em>OR</em> posted form data.
>>>
>>> 2. Resteasy already has a workaround for Tomcat:
>>>
>>> // Tomcat does not set getParameters() if it is a PUT request
>>> // so pull it out manually
>>> if (request.getMethod().equals("PUT") &&
>>> (request.getParameterMap() == null ||
>>> request.getParameterMap().isEmpty()))
>>> {
>>> return getPutFormParameters();
>>> }
>>>
>>> where getPutFormParameters() pulls form parameters directly from the
>>> input stream. I'm thinking of adding this:
>>>
>>> Map<String, String[]> parameterMap = request.getParameterMap();
>>> MultivaluedMap<String, String> queryMap =
>>> uri.getQueryParameters();
>>> if (mapEquals(parameterMap, queryMap))
>>> {
>>> return getPutFormParameters();
>>> }
>>>
>>> In other words, it's a test that request.getParameterMap() contains
>>> only query parameters.
>>>
>>> My next question is, is this safe? Is it possible that the input
>>> stream has already been read?
>>>
>> The web container only processes URL encoded POSTs, not any other method
>> (as per the spec).
>>
>> Although it is a convenient API, it is possible that the integrated
>> processing is very resource intensive compared to what is actually
>> needed, with questionable scalability, since it parses everything down
>> to individual strings, and puts everything in a hash map.
>>
>> Rémy
>>
>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Ron S. <rs...@re...> - 2012-10-15 17:11:10
|
On 10/15/2012 09:36 AM, Rémy Maucherat wrote:
> On 10/14/2012 07:27 AM, Ron Sigal wrote:
>> Hi Remy,
>>
>> I'm working on RESTEASY-760 "@FormParam does not work with PUT method
>> when a Query param is present", in which the reporter claims (and
>> I've verified the behavior), that if he sends a request with both
>> query parameters and form parameters, Resteasy doesn't pass the form
>> parameters into his JAX-RS resource. It seems that in jbossweb,
>> org.apache.catalina.connector.RequestFacade.getParameterMap() returns
>> only query parameters, despite the javadoc on
>> javax.servlet.ServletRequest.getParameterMap(), which says
>>
>> /**
>> * Returns a java.util.Map of the parameters of this request.
>> *
>> * <p>Request parameters are extra information sent with the
>> request.
>> * For HTTP servlets, parameters are contained in the query
>> string or
>> * posted form data.
>> *
>> * @return an immutable java.util.Map containing parameter names as
>> * keys and parameter values as map values. The keys in the
>> parameter
>> * map are of type String. The values in the parameter map are of
>> type
>> * String array.
>> */
>>
>> 1. Is this behavior a bug in jbossweb? I don't see any jbossweb
>> parameters that override the behavior. Granted, the javadoc is a
>> little ambiguous, where it says, "parameters are contained in the
>> query string <em>OR</em> posted form data.
>>
>> 2. Resteasy already has a workaround for Tomcat:
>>
>> // Tomcat does not set getParameters() if it is a PUT request
>> // so pull it out manually
>> if (request.getMethod().equals("PUT") &&
>> (request.getParameterMap() == null ||
>> request.getParameterMap().isEmpty()))
>> {
>> return getPutFormParameters();
>> }
>>
>> where getPutFormParameters() pulls form parameters directly from the
>> input stream. I'm thinking of adding this:
>>
>> Map<String, String[]> parameterMap = request.getParameterMap();
>> MultivaluedMap<String, String> queryMap =
>> uri.getQueryParameters();
>> if (mapEquals(parameterMap, queryMap))
>> {
>> return getPutFormParameters();
>> }
>>
>> In other words, it's a test that request.getParameterMap() contains
>> only query parameters.
>>
>> My next question is, is this safe? Is it possible that the input
>> stream has already been read?
>>
> The web container only processes URL encoded POSTs, not any other
> method (as per the spec).
I get the same result, i.e., missing form parameters in
getParameterMap(), with POST.
>
> Although it is a convenient API, it is possible that the integrated
> processing is very resource intensive compared to what is actually
> needed, with questionable scalability, since it parses everything down
> to individual strings, and puts everything in a hash map.
>
> Rémy
>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Ron S. <rs...@re...> - 2012-10-15 17:25:30
|
On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
> On 10/15/2012 03:40 PM, Bill Burke wrote:
>> Please move these types of discussions to the dev list.
> Ok, but I am not subscribed to it.
WHAT?!?! I thought everyone was on the Resteasy dev list. I'm pretty
sure Francois Holland is on the list. Also, Voltaire. But not Marie Le
Pen. She's on the jersey dev list. ;)
>>
>> But, for form processing, there's a few things you have to worry about.
>>
>> 1) Did a Servlet filter eat the input stream? You'll need to use
>> getParameterMap() then.
>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>> input stream or not?
>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>> up shit creek.
> The spec is quite clear that it deals with URL encoded POSTs, so I
> understand the real problems started when other containers thought it
> would be nice to ignore specs and do what users asked for. So the
> option to also process PUT should be added to AS then ?
I'm not sure why the user wants to use PUT. But I get the same problem
with POST. Here's my test, on the client side:
@Test
public void testFormParamWithQueryParamPost() throws Exception
{
ClientRequest request = new
ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
request.formParameter("formParam", "abc");
request.header("Content-Type", "application/x-www-form-urlencoded");
ClientResponse<String> response = request.put(String.class);
assertTrue(response != null);
System.out.println("response: " + response.getEntity());
assertEquals("abc", response.getEntity());
}
When Resteasy calls
javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
query=xyz but not formParam=abc. Maybe I'm doing something wrong?
>
> Rémy
>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Ron S. <rs...@re...> - 2012-10-15 17:34:05
|
On 10/15/2012 01:21 PM, Rémy Maucherat wrote: > On 10/15/2012 07:10 PM, Ron Sigal wrote: >> >> >> On 10/15/2012 09:36 AM, Rémy Maucherat wrote: >>> >>> The web container only processes URL encoded POSTs, not any other >>> method (as per the spec). >> >> I get the same result, i.e., missing form parameters in >> getParameterMap(), with POST. > It is normal that the query parameters are always parsed. > > The body parameters will then be parsed if it is a POST with the form > encoding content type and the body is not too large (2MB max). A > chunked body used to not be supported as well, but it is now supported. Do I have to do something to trigger the parsing of the body parameters? > > Rémy > -- My company's smarter than your company (unless you work for Red Hat). |
|
From: Ron S. <rs...@re...> - 2012-10-15 17:43:45
|
My mistake. I was using PUT when I thought I was using POST. For POST,
jbossweb returns both the query and the form parameters.
So, I guess the answer is: USE POST. FORGET PUT. Is that reasonable?
Or, I can include my fix that makes it work with PUT. Bill, wdyt?
Sorry for the confusion, Remy. :(
On 10/15/2012 01:25 PM, Ron Sigal wrote:
>
> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>> Please move these types of discussions to the dev list.
>> Ok, but I am not subscribed to it.
> WHAT?!?! I thought everyone was on the Resteasy dev list. I'm pretty
> sure Francois Holland is on the list. Also, Voltaire. But not Marie Le
> Pen. She's on the jersey dev list. ;)
>
>>> But, for form processing, there's a few things you have to worry about.
>>>
>>> 1) Did a Servlet filter eat the input stream? You'll need to use
>>> getParameterMap() then.
>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>> input stream or not?
>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>> up shit creek.
>> The spec is quite clear that it deals with URL encoded POSTs, so I
>> understand the real problems started when other containers thought it
>> would be nice to ignore specs and do what users asked for. So the
>> option to also process PUT should be added to AS then ?
> I'm not sure why the user wants to use PUT. But I get the same problem
> with POST. Here's my test, on the client side:
>
> @Test
> public void testFormParamWithQueryParamPost() throws Exception
> {
> ClientRequest request = new
> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
> request.formParameter("formParam", "abc");
> request.header("Content-Type", "application/x-www-form-urlencoded");
> ClientResponse<String> response = request.put(String.class);
> assertTrue(response != null);
> System.out.println("response: " + response.getEntity());
> assertEquals("abc", response.getEntity());
> }
>
> When Resteasy calls
> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
> query=xyz but not formParam=abc. Maybe I'm doing something wrong?
>
>> Rémy
>>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Ron S. <rs...@re...> - 2012-10-15 17:59:56
|
Ok, I see
> SRV.4.1.1
> When Parameters Are Available
> The following are the conditions that must be met before post form
> data will
> be populated to the parameter set:
> 1. The request is an HTTP or HTTPS request.
> 2. The HTTP method is POST
> 3. The content type is application/x-www-form-urlencoded
> 4. The servlet has made an initial call of any of the getParameter
> family of meth-
> ods on the request object.
> If the conditions are not met and the post form data is not included
> in the
> parameter set, the post data must still be available to the servlet
> via the request
> object’s input stream. If the conditions are met, post form data will
> no longer be
> available for reading directly from the request object’s input stream.
in the Servlet spec. That seems to settle it.
Thanks, Remy.
On 10/15/2012 01:43 PM, Ron Sigal wrote:
> My mistake. I was using PUT when I thought I was using POST. For POST,
> jbossweb returns both the query and the form parameters.
>
> So, I guess the answer is: USE POST. FORGET PUT. Is that reasonable?
>
> Or, I can include my fix that makes it work with PUT. Bill, wdyt?
>
> Sorry for the confusion, Remy. :(
>
> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>> Please move these types of discussions to the dev list.
>>> Ok, but I am not subscribed to it.
>> WHAT?!?! I thought everyone was on the Resteasy dev list. I'm pretty
>> sure Francois Holland is on the list. Also, Voltaire. But not Marie Le
>> Pen. She's on the jersey dev list. ;)
>>
>>>> But, for form processing, there's a few things you have to worry about.
>>>>
>>>> 1) Did a Servlet filter eat the input stream? You'll need to use
>>>> getParameterMap() then.
>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>> input stream or not?
>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>> up shit creek.
>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>> understand the real problems started when other containers thought it
>>> would be nice to ignore specs and do what users asked for. So the
>>> option to also process PUT should be added to AS then ?
>> I'm not sure why the user wants to use PUT. But I get the same problem
>> with POST. Here's my test, on the client side:
>>
>> @Test
>> public void testFormParamWithQueryParamPost() throws Exception
>> {
>> ClientRequest request = new
>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>> request.formParameter("formParam", "abc");
>> request.header("Content-Type", "application/x-www-form-urlencoded");
>> ClientResponse<String> response = request.put(String.class);
>> assertTrue(response != null);
>> System.out.println("response: " + response.getEntity());
>> assertEquals("abc", response.getEntity());
>> }
>>
>> When Resteasy calls
>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>> query=xyz but not formParam=abc. Maybe I'm doing something wrong?
>>
>>> Rémy
>>>
--
My company's smarter than your company (unless you work for Red Hat).
|
|
From: Bill B. <bb...@re...> - 2012-10-15 19:45:09
|
Err...PUT has meaning. PUT + form parameters should be supported.
On 10/15/2012 1:43 PM, Ron Sigal wrote:
> My mistake. I was using PUT when I thought I was using POST. For POST,
> jbossweb returns both the query and the form parameters.
>
> So, I guess the answer is: USE POST. FORGET PUT. Is that reasonable?
>
> Or, I can include my fix that makes it work with PUT. Bill, wdyt?
>
> Sorry for the confusion, Remy. :(
>
> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>>
>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>> Please move these types of discussions to the dev list.
>>> Ok, but I am not subscribed to it.
>> WHAT?!?! I thought everyone was on the Resteasy dev list. I'm pretty
>> sure Francois Holland is on the list. Also, Voltaire. But not Marie Le
>> Pen. She's on the jersey dev list. ;)
>>
>>>> But, for form processing, there's a few things you have to worry about.
>>>>
>>>> 1) Did a Servlet filter eat the input stream? You'll need to use
>>>> getParameterMap() then.
>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>> input stream or not?
>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>> up shit creek.
>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>> understand the real problems started when other containers thought it
>>> would be nice to ignore specs and do what users asked for. So the
>>> option to also process PUT should be added to AS then ?
>> I'm not sure why the user wants to use PUT. But I get the same problem
>> with POST. Here's my test, on the client side:
>>
>> @Test
>> public void testFormParamWithQueryParamPost() throws Exception
>> {
>> ClientRequest request = new
>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>> request.formParameter("formParam", "abc");
>> request.header("Content-Type", "application/x-www-form-urlencoded");
>> ClientResponse<String> response = request.put(String.class);
>> assertTrue(response != null);
>> System.out.println("response: " + response.getEntity());
>> assertEquals("abc", response.getEntity());
>> }
>>
>> When Resteasy calls
>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>> query=xyz but not formParam=abc. Maybe I'm doing something wrong?
>>
>>> Rémy
>>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Ron S. <rs...@re...> - 2012-10-16 01:55:29
|
Ok, I've put in the fix.
On 10/15/2012 03:29 PM, Bill Burke wrote:
> Err...PUT has meaning. PUT + form parameters should be supported.
>
> On 10/15/2012 1:43 PM, Ron Sigal wrote:
>> My mistake. I was using PUT when I thought I was using POST. For POST,
>> jbossweb returns both the query and the form parameters.
>>
>> So, I guess the answer is: USE POST. FORGET PUT. Is that reasonable?
>>
>> Or, I can include my fix that makes it work with PUT. Bill, wdyt?
>>
>> Sorry for the confusion, Remy. :(
>>
>> On 10/15/2012 01:25 PM, Ron Sigal wrote:
>>> On 10/15/2012 12:12 PM, Rémy Maucherat wrote:
>>>> On 10/15/2012 03:40 PM, Bill Burke wrote:
>>>>> Please move these types of discussions to the dev list.
>>>> Ok, but I am not subscribed to it.
>>> WHAT?!?! I thought everyone was on the Resteasy dev list. I'm pretty
>>> sure Francois Holland is on the list. Also, Voltaire. But not Marie Le
>>> Pen. She's on the jersey dev list. ;)
>>>
>>>>> But, for form processing, there's a few things you have to worry about.
>>>>>
>>>>> 1) Did a Servlet filter eat the input stream? You'll need to use
>>>>> getParameterMap() then.
>>>>> 2) Is it a POST or PUT? If PUT, does getParameterMap() eat the form
>>>>> input stream or not?
>>>>> 3) If its Tomcat, a PUT, and the filter ate the input stream, you're
>>>>> up shit creek.
>>>> The spec is quite clear that it deals with URL encoded POSTs, so I
>>>> understand the real problems started when other containers thought it
>>>> would be nice to ignore specs and do what users asked for. So the
>>>> option to also process PUT should be added to AS then ?
>>> I'm not sure why the user wants to use PUT. But I get the same problem
>>> with POST. Here's my test, on the client side:
>>>
>>> @Test
>>> public void testFormParamWithQueryParamPost() throws Exception
>>> {
>>> ClientRequest request = new
>>> ClientRequest("http://localhost:8080/RESTEASY-760/post/query?query=xyz");
>>> request.formParameter("formParam", "abc");
>>> request.header("Content-Type", "application/x-www-form-urlencoded");
>>> ClientResponse<String> response = request.put(String.class);
>>> assertTrue(response != null);
>>> System.out.println("response: " + response.getEntity());
>>> assertEquals("abc", response.getEntity());
>>> }
>>>
>>> When Resteasy calls
>>> javax.servlet.http.HttpServletRequest..getParameterMap(), it gets
>>> query=xyz but not formParam=abc. Maybe I'm doing something wrong?
>>>
>>>> Rémy
>>>>
--
My company's smarter than your company (unless you work for Red Hat).
|
Thanks for helping keep SourceForge clean.
X