You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/11/19 05:12:06 UTC
AsyncWeb HTTP codec is in mina-filter-codec-http now.
Hi folks,
I've just succeeded to import AsyncWeb HTTP codec into
mina-filter-codec-http submodule in trunk. I had to rewrite the
client side codec, but it seems like it's working OK. Please note
this is a massive change so you might see a lot of compilation errors
if you were using the HTTP client codec in the trunk. The notable
changes are mostly renaming: HttpProtocolCodecFactory ->
HttpCodecFactory, HttpRequestMessage -> HttpRequest,
HttpResponseMessage -> HttpResponse. You will also find subtle
differences in message model, but it should be easy to follow up.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 27, 2007 1:24 AM, monika7 <mo...@maco-tech.com> wrote:
> Trustin Lee wrote:
> >
> > On Nov 19, 2007 10:19 PM, Irving, Dave <da...@bankofamerica.com>
> > wrote:
> >> > I don't see a use case where I want *not* to call normalize()
> >> > and break HTTP compatibility... but I don't have enough imagination :)
> >>
> >> Me neither. I'd think you'd want normalize() always being called in the
> >> codec.
> >
> > Great to see you in the mailing list. :)
> >
> > I've just added a call to MutableHttpRequest.normalize() in
> > HttpRequestEncoder.
> >
> >
> >
>
> There is also a normalize() method available for MutableHttpResponse - will
> this one also be called in the codec?
You have to call MutableHttpResponse.normalize by yourself because it
needs parameter that the encoder doesn't have access to.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by monika7 <mo...@maco-tech.com>.
Trustin Lee wrote:
>
> On Nov 19, 2007 10:19 PM, Irving, Dave <da...@bankofamerica.com>
> wrote:
>> > I don't see a use case where I want *not* to call normalize()
>> > and break HTTP compatibility... but I don't have enough imagination :)
>>
>> Me neither. I'd think you'd want normalize() always being called in the
>> codec.
>
> Great to see you in the mailing list. :)
>
> I've just added a call to MutableHttpRequest.normalize() in
> HttpRequestEncoder.
>
>
>
There is also a normalize() method available for MutableHttpResponse - will
this one also be called in the codec?
Monika
--
View this message in context: http://www.nabble.com/AsyncWeb-HTTP-codec-is-in-mina-filter-codec-http-now.-tf4833201s16868.html#a13952999
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 19, 2007 10:19 PM, Irving, Dave <da...@bankofamerica.com> wrote:
> > I don't see a use case where I want *not* to call normalize()
> > and break HTTP compatibility... but I don't have enough imagination :)
>
> Me neither. I'd think you'd want normalize() always being called in the
> codec.
Great to see you in the mailing list. :)
I've just added a call to MutableHttpRequest.normalize() in HttpRequestEncoder.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
RE: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by "Irving, Dave" <da...@bankofamerica.com>.
> I don't see a use case where I want *not* to call normalize()
> and break HTTP compatibility... but I don't have enough imagination :)
Me neither. I'd think you'd want normalize() always being called in the
codec.
Dave
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Jeff Mesnil <jm...@redhat.com>.
Hi Trustin,
Trustin Lee wrote:
> On Nov 19, 2007 9:31 PM, Trustin Lee <tr...@gmail.com> wrote:
>> 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.
Thansk, calling normalize() fixes the issue (my local tests are now 100%
green).
However, I'd prefer if the call to normalize() was done by the codec.
Without that normalization, the requests that are sent are not HTTP
compliant (wether they are GET or POST for that matter) and won't be
usable by anybody including mina's own HttpRequestDecoder.
I don't see a use case where I want *not* to call normalize() and break
HTTP compatibility... but I don't have enough imagination :)
--
jeff
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 19, 2007 9:31 PM, Trustin Lee <tr...@gmail.com> wrote:
>
> On Nov 19, 2007 9:10 PM, Jeff Mesnil <jm...@redhat.com> 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
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 19, 2007 9:10 PM, Jeff Mesnil <jm...@redhat.com> 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. :)
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Jeff Mesnil <jm...@redhat.com>.
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).
hope it helps,
jeff
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
On Nov 19, 2007 5:41 PM, Jeff Mesnil <jm...@redhat.com> wrote:
> Hi Trustin,,
>
> Trustin Lee wrote:
> > Hi folks,
> >
> > I've just succeeded to import AsyncWeb HTTP codec into
> > mina-filter-codec-http submodule in trunk. I had to rewrite the
> > client side codec, but it seems like it's working OK. Please note
> > this is a massive change so you might see a lot of compilation errors
> > if you were using the HTTP client codec in the trunk. The notable
> > changes are mostly renaming: HttpProtocolCodecFactory ->
> > HttpCodecFactory, HttpRequestMessage -> HttpRequest,
> > HttpResponseMessage -> HttpResponse. You will also find subtle
> > differences in message model, but it should be easy to follow up.
>
> I've tested the new code in mina-filter-codec-http & asyncweb-core and I
> encountered a few problems:
>
> 1/ asyncweb-core does not compile because class HttpHeaderConstants
> (from mina-filter-codec-http) is referenced by asyncweb-core's
> AbstractHttpServiceContext but is not public (package visibility only)
>
> 2/ there is a "typo" in mina-filter-codec-http's HttpRequestDecoder: the
> DecodingStateMachine to use is Http*Request*DecodingState, not
> Http*Response*DecodingState
Oops! I am sorry about these silly problems. They were all fixed
now. Just in case you are using the classes in AsyncWeb, you don't
need to do that if you just want a simplistic HTTP client/server.
> 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?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Jeff Mesnil <jm...@redhat.com>.
Hi Trustin,,
Trustin Lee wrote:
> Hi folks,
>
> I've just succeeded to import AsyncWeb HTTP codec into
> mina-filter-codec-http submodule in trunk. I had to rewrite the
> client side codec, but it seems like it's working OK. Please note
> this is a massive change so you might see a lot of compilation errors
> if you were using the HTTP client codec in the trunk. The notable
> changes are mostly renaming: HttpProtocolCodecFactory ->
> HttpCodecFactory, HttpRequestMessage -> HttpRequest,
> HttpResponseMessage -> HttpResponse. You will also find subtle
> differences in message model, but it should be easy to follow up.
I've tested the new code in mina-filter-codec-http & asyncweb-core and I
encountered a few problems:
1/ asyncweb-core does not compile because class HttpHeaderConstants
(from mina-filter-codec-http) is referenced by asyncweb-core's
AbstractHttpServiceContext but is not public (package visibility only)
2/ there is a "typo" in mina-filter-codec-http's HttpRequestDecoder: the
DecodingStateMachine to use is Http*Request*DecodingState, not
Http*Response*DecodingState
3/ in the same state machine, the parameters of HTTP request are not
decoded (still figuring this one out though...)
hope it helps,
jeff
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
Hi Monika,
On Nov 27, 2007 1:21 AM, monika7 <mo...@maco-tech.com> wrote:
>
>
> Trustin Lee wrote:
> >
> > Hi Monica,
> >
> > On Nov 22, 2007 4:58 AM, monika7 <mo...@maco-tech.com> wrote:
> >> I just discovered the new version of HTTPResponse vs old
> >> HTTPResponseMessage
> >> and I noticed one difference in the outcome of getContent() method.
> >> The original HTTPResponseMessage had getStringContent() method which
> >> returned just the body of the message. If I use HTTPResponse.getContent
> >> and
> >> convert the return IOBuffer to a String, I get the whole message,
> >> including
> >> all http headers. I am enclosing below the output of the following code
> >> where httpResponse is instance of DefaultHttpResponse class:
> >>
> >> IoBuffer content = httpResponse.getContent();
> >> byte[] contentBytes = content.array();
> >> String contentString = new String(contentBytes);
> >
> > I think you have to do the following:
> >
> > IoBuffer content = httpResponse.getContent();
> > String contentString =
> > content.getString(Charset.forName(...).newDecoder());
> >
> >
>
> This worked, so now my http client is fixed.
> If I were to use the same HTTPResponse/Request objects on my server side
> (instead of the classes in http server example) - can you give some pointers
> what need to be done to do the conversion. Would the same HttpCodecFactory I
> used on client side work on the server side?
Yes, the same HttpCodecFactory is used. It automatically decides what
encoder and decoder is going to be used.
You could take a look at the following example:
http://svn.apache.org/viewvc/mina/sandbox/asyncweb/example/src/main/java/org/safehaus/asyncweb/example/lightweight/
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by monika7 <mo...@maco-tech.com>.
Trustin Lee wrote:
>
> Hi Monica,
>
> On Nov 22, 2007 4:58 AM, monika7 <mo...@maco-tech.com> wrote:
>> I just discovered the new version of HTTPResponse vs old
>> HTTPResponseMessage
>> and I noticed one difference in the outcome of getContent() method.
>> The original HTTPResponseMessage had getStringContent() method which
>> returned just the body of the message. If I use HTTPResponse.getContent
>> and
>> convert the return IOBuffer to a String, I get the whole message,
>> including
>> all http headers. I am enclosing below the output of the following code
>> where httpResponse is instance of DefaultHttpResponse class:
>>
>> IoBuffer content = httpResponse.getContent();
>> byte[] contentBytes = content.array();
>> String contentString = new String(contentBytes);
>
> I think you have to do the following:
>
> IoBuffer content = httpResponse.getContent();
> String contentString =
> content.getString(Charset.forName(...).newDecoder());
>
>
This worked, so now my http client is fixed.
If I were to use the same HTTPResponse/Request objects on my server side
(instead of the classes in http server example) - can you give some pointers
what need to be done to do the conversion. Would the same HttpCodecFactory I
used on client side work on the server side?
Monika
--
View this message in context: http://www.nabble.com/AsyncWeb-HTTP-codec-is-in-mina-filter-codec-http-now.-tf4833201s16868.html#a13952973
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by Trustin Lee <tr...@gmail.com>.
Hi Monica,
On Nov 22, 2007 4:58 AM, monika7 <mo...@maco-tech.com> wrote:
> I just discovered the new version of HTTPResponse vs old HTTPResponseMessage
> and I noticed one difference in the outcome of getContent() method.
> The original HTTPResponseMessage had getStringContent() method which
> returned just the body of the message. If I use HTTPResponse.getContent and
> convert the return IOBuffer to a String, I get the whole message, including
> all http headers. I am enclosing below the output of the following code
> where httpResponse is instance of DefaultHttpResponse class:
>
> IoBuffer content = httpResponse.getContent();
> byte[] contentBytes = content.array();
> String contentString = new String(contentBytes);
I think you have to do the following:
IoBuffer content = httpResponse.getContent();
String contentString = content.getString(Charset.forName(...).newDecoder());
Please let me know if this doesn't work.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: AsyncWeb HTTP codec is in mina-filter-codec-http now.
Posted by monika7 <mo...@maco-tech.com>.
Trustin Lee wrote:
>
> Hi folks,
>
> I've just succeeded to import AsyncWeb HTTP codec into
> mina-filter-codec-http submodule in trunk. I had to rewrite the
> client side codec, but it seems like it's working OK. Please note
> this is a massive change so you might see a lot of compilation errors
> if you were using the HTTP client codec in the trunk. The notable
> changes are mostly renaming: HttpProtocolCodecFactory ->
> HttpCodecFactory, HttpRequestMessage -> HttpRequest,
> HttpResponseMessage -> HttpResponse. You will also find subtle
> differences in message model, but it should be easy to follow up.
>
> Cheers,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
>
I just discovered the new version of HTTPResponse vs old HTTPResponseMessage
and I noticed one difference in the outcome of getContent() method.
The original HTTPResponseMessage had getStringContent() method which
returned just the body of the message. If I use HTTPResponse.getContent and
convert the return IOBuffer to a String, I get the whole message, including
all http headers. I am enclosing below the output of the following code
where httpResponse is instance of DefaultHttpResponse class:
IoBuffer content = httpResponse.getContent();
byte[] contentBytes = content.array();
String contentString = new String(contentBytes);
------begin contentString------
HTTP/1.1 200 OK
Connection: keep-alive
Date: Wed, 21 Nov 2007 14:29:01 EST
Keep-Alive: 200
Content-Type: text/plain
Server: HttpServer (Test HTTP Server)
Last-Modified: Wed, 21 Nov 2007 14:29:01 EST
Cache-Control: private
Content-Length: 171
sample body
--------------end contentString--------
Old getStringContent() would have returned just ---sample body---
Was that done intentionally and if yes, do you think, you can you provide a
convenience method for getting just the body (as String ??).
For clarification, on client side I am using the latest
HTTPRequest/Response/Codec code from mina-filter-codec-http, but on the
server side I am still using the code from examples/httpserver.
Thanks,
Monika Adamczyk
--
View this message in context: http://www.nabble.com/AsyncWeb-HTTP-codec-is-in-mina-filter-codec-http-now.-tf4833201s16868.html#a13884815
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.