hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Parsing http parameters
Date Sat, 28 Jul 2007 12:07:29 GMT
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 <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
>         
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message