Hello Marcus, > I have created a http server package for my project abstractcache.sf.net (not > released yet). I have used the httpcore components to build a BIO server > which performs really well.
It's great that you found the package useful. Thanks for letting us know. > Since I'm quite familiar with the servlet spec I assumed that > HttpRequest.getParams actually would return the parsed query string in the > GET case and the parsed body in the POST case. HttpCore is in no way an alternative to the Servlet API. We're not building a web container or any such thing. We're building a core library for HTTP communication. The closest thing to a server-side handler we have is class HttpService in the protocol package, and the package description mentions that we don't recommend it as an alternative to the Servlet API: http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore/apidocs/org/apache/http/protocol/package-summary.html All get/setParams refer to parameters for our framework, as provided by implementations of interface HttpParams: http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore/apidocs/org/apache/http/params/HttpParams.html > I have gone through your xref and javadocs for 2 hours now and cannot find > any parsing facilities which does parameter parsing. Headers are parsed I > see. We need to parse headers in order to execute HTTP. There is no reason for us to parse a query string, let alone a message entity. It is not relevant for executing HTTP. We only need the scheme and target host of a URI. In the old HttpClient 3.x code, there is a class URI that you could use for the query string. But you might as well use java.net.URI. > Both of these are quite easy to parse but I thought that it was done already > since the package otherwise is in such a complete state. But you perhaps > want to leave parameter parsing to the implementor of the core package. Parameter parsing is an application level problem. It is not in the scope of HttpComponents, certainly not of core. At the moment, we're not dealing with content anywhere, we just pass it through. There might be a case for convenience entities somewhere in HttpClient 4.0, but even those wouldn't be concerned with query strings. We will discuss whether to port the multipart request entity from 3.1 to 4.0 later this year. That's outgoing though (client), not incoming (server). If you want a request representation with parameters, you will have to define your own interfaces and implementations. You can extend the HttpRequest of course. But parsing and storing the parameters from the query string or message body will remain the task of your application. HttpCore scope ends when the message is delivered to your application. hope that helps, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
