On Fri, 2007-07-27 at 21:11 +0200, Marcus Herou wrote: > Yes thanks for clearing some tings out. > > Of course I never wanted it to be an alternative to the servlet-spec, > however the way I tend to build stuff get's so modular so it's almost > implementing the spec once again :) Bind different requesthandlers to > different uri's is scary close to the httpservlet binding. But it's > probably only because it's actually a a smart way of looking up > executable code. > > First I started off bulding a server with my own proprietary protocol > which worked just fine. After a while building clients for different > languages I came to the conclusion that it would be smarter to use the > http protocol instead to ease the spread and implementations, > understanding, testing etc of the abstractcache project. > > I have solved the parsing of both GET and POST requests now but as I > stated before I find the implementation of the solution to be in the > wrong place. > > Let's say I wanna contribute to the project by adding some parsing. > Where would you start ? > > Something like this perhaps: > 1. Create a ParsedHttpRequest which extends HttpRequest and some > implementations of it for POST and GET. > 2. Creating a new RequestFactory which purpose is to produce a > ParsedHttpRequest > Yes that's sound cleanest right ? >
Hi Marcus That sounds reasonable to me. We actually use a very similar approach in HttpClient to extend basic HTTP requests with ability to interact with the request URI as a java.net.URI object http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpclient/trunk/module-client/src/main/java/org/apache/http/client/methods/HttpUriRequest.java > I hope you forgive my naming suggestions since if it is something I'm > bad at so is it naming conventions :) > > If it's clean enough don't you think it could be supplied in a > "contrib" package or something ? > I personally will be in favor of accepting this code into the contrib package. > BYTW I created my own HttpServerConnection since I found it a little > strange to set both sendBufferSize and receiveBufferSize to the same > sizes. > > I came to think of this since I wanted to set the socket options right > after the socket was accepted way before http comes into play and > found that the socket options was overridden. After some grepping I > found this bastard :) > > Think of it... Let's say an implementor already set his fantastic > combo of socket options then it should'nt be set again right? > > I attach my version of the HttpServerConnection so you just can look > at it if you'd like. > How about moving socket initialization code from SocketHttp*Connection to DefaultHttp*Connection classes? Would that address the issue? > Anyway I'm not here for complaining I really really love your work! > Hope you don't take my pointers as dark criticism. I just wanna > contribute since I have been a leech for too long, time to become a > seeder instead... > I love constructive criticism, dark or colored otherwise. It can actually help look at things from a different angle. Cheers Oleg > > Kindly > > //Marcus > > > > > > > Kindly > > //Marcus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No I just wanted something which took care of the http protocol and in > my opinion parameters are included into > > On 7/27/07, Roland Weber <[EMAIL PROTECTED]> wrote: > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
