[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

[trustin]

I have reviewed the code and made some quick modification by myself (mostly renaming and access modifier changes):

http://fisheye.jboss.org/changelog/Netty/branches/Branch_HTTP

I think there's only a couple issues left now.

1) What I meant was actually that HttpRequest.getUri() should be retained and all parameter accessor methods need to be removed.  Then, HttpRequestEncoder and HttpRequestDecoder won't need to build or decode an URI at all.  Just calling URI.toString() and new URI(String) would be enough.

Now assuming that we don't have any parameter accessor methods but URI property, how do we encode / decode a query in JBM?  There are a few choices:

1a) Use GET method and append a usual query string to the URI.  The query string is encoded by QueryStringEncoder, which replaces UriBuilder.
1b) Use POST method and put the query string into the content of the HttpMessage.  The query string is encoded by QueryStringEncoder, which replaces UriBuilder.
1c) Use REST style URI and use regular expression matching.  (No need for UriBuilder, UriQueryDecoder, etc)

QueryStringEncoder should be pretty much same with UriBuilder except that it builds a query string part only - it's just renaming and removing several lines.

Also, UriQueryDecoder should be renamed to QueryStringDecoder and modified to start to decode the specified String or URI from the first occurrence of '?'.

The removal of the parameter accessor methods makes HttpRequest closer to the original HTTP request message model specified by the relevant standards.  There's no restriction in how a query string should look like, and we can't assume that a query string always exists in the URI - it can even exist in the content in case of POST, and actually it's entirely up to how a user wants to use HTTP.  That's why I'd like to isolate query string (or parameter) processing from the core classes.  A user can always use utility classes (QueryStringEncoder/Decoder) if necessary.

2) (optional - UTF-8 only support is fine at this moment) QueryStringEncoder and QueryStringDecoder should consider charsets.  A sensible default could be UTF-8, but some people might want something like EUC-JP.  Adding an optional charset  parameter to the constructor would be just fine.

Please let me know if I am missing something.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188685#4188685

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188685