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

[ataylor]

anonymous wrote : I'd like to know if there was any difficulty in implementing HTTP on top of Netty so that I can make the Netty API more user-friendly. :) 

The API was cool Trustin. Especially the ReplayingDecoder, it makes decoding complex messages much easier.

anonymous wrote : 1) IIUC, HTTP allows multiple headers with the same key. It seems like the current HttpMessage interface assumes there's only one value per key. Therefore, the headers should be represented as Set<String, List> instead of Map<String, String>. 

Ok, thats done and ive changed the API.

anonymous wrote : 2) HTTP allows multiple parameters with the same key. Therefore, the parameters should be represented as Set<String, List> instead of Map<String, String>. (Same with the issue 1) 

also done

anonymous wrote : 3) I'm not sure if a multi-line header is decoded correctly: 

no, you are correct. If i understand this correctly it should be as follows.

A header valu ecan be on multiple lines if the next line starts with a space or tab, so:

aheader: abcdefg
  |  hij

would be the same as:

aheader: abcdefghij

also multiple values are seperated by a comma, i.e.

aheader: a,b,c

actually has 3 values a, b and c. The caveat here is Date type headers such as Date, Expires etc as they have commas within them.

anonymous wrote : 4) Reason (error message) is missing in HttpResponse. HttpResponseStatusCode already has the pre-defined reason phrases, but it should be customizable on a per-response basis. (Perhaps we could simply make the HttpResponseStatusCode constructor public?) 

enums can't have public constructors so ive added another static method for overriding the reason description.

anonymous wrote : 5) What about renaming HttpProtocol to HttpVersion? P of HTTP already stands for 'protocol'. Also, HttpRequest.get/setProtocol() needs to be renamed to get/setVersion() or get/setProtocolVersion(). 

I agree, done.

anonymous wrote : 6) java.net.URI already has a query property. I think we don't need the parameter accessor methods in the HttpRequest interface. We could provide a helper class like UriBuilder later.

not sure i follow completely, i need the URI for encoding purposes so i need an accessor. Unless you meant replace it with a String?

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

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