On Nov 19, 2007 9:31 PM, Trustin Lee <[EMAIL PROTECTED]> wrote: > > On Nov 19, 2007 9:10 PM, Jeff Mesnil <[EMAIL PROTECTED]> wrote: > > Hi Trustin, > > > > Thanks for the quick fixes. > > > > Trustin Lee wrote: > > >> 3/ in the same state machine, the parameters of HTTP request are not > > >> decoded (still figuring this one out though...) > > > > > > What HTTP method are you using? > > > > I'm currently using the GET method. > > I think I found the problem. Request decoding is working as expected. > > The issue is in HttpRequestEncoder. When encoding the URI, the > > parameters set on the request are not appended to the URI's query. > > Of course, this should apply to GET and HEAD methods only afaik. > > > > The API is not really consistent here. > > I expect to use HttpRequest.setParameter(key, value) regardless of the > > HTTP method I use. It is then up to the codec to append it to query > > string or not. > > This may also imply that the getRequestUri() method should return an > > up-to-date URI every time parameters are changed (if the method is GET > > or HEAD). > > Yep, I thought the same, but updating requestUri every time is too > expensive. As an alternative, there's 'normalize()' method in > MutableHttpRequest (and consequently in DefaultHttpRequest). It adds > proper header fields and updates requestUri when there are one or more > parameters. I didn't call normalize() explicitly in the encoder for > those who wants to do something special (?). Please let me know if > there will never be such a case. :)
I've just updated JavaDoc that tells you have to call normalize() by yourself to update the requestUri property to avoid confusion. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
