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 Sat, 28 Jul 2007 12:28:51 GMT
Cool.

Then I guess I should extend the HttpUriRequest instead ?

Something like this perhaps ?
public interface ParsedHttpRequest extends HttpUriRequest
{
   Map<String, String[]> getParameters();
   String getParameter(String name);
}

Hmmm... No not involving httpclient into something which should be more
core... and httpclient sound bad for something which resides on the server
:)
I think actually I will make a merge of httpclient's HttpUriRequest with the
ParsedParameterRequest and put it in a package named something like
org.apache.http.* somewhere.

Re:
"How about moving socket initialization code from SocketHttp*Connection
to DefaultHttp*Connection classes? Would that address the issue?"

Hmm well yes an extension which only binds the socket, why not. However the
socket is private in the Socket* so "this.socket=socket" cannot be setup
from an extended class... That's why I did'nt subclass the DefaultHttp*
class in the first way. Any thoughts ? Looked at my code ?

Kindly

//Marcus



Kindly

//Marcus












On 7/28/07, Oleg Kalnichevski <olegk@apache.org> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message