hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Herou" <marcushe...@gmail.com>
Subject Re: Parsing http parameters
Date Fri, 27 Jul 2007 19:11:41 GMT
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

Yes that's sound cleanest right ?

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 ?

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.

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...





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 <ossfwot@dubioso.net> 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org

View raw message