You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Marcus Herou <ma...@gmail.com> on 2007/07/27 19:54:34 UTC
Parsing http parameters
Since I tend to be stuck in the spam filter I don't supply any code in the
mail.
--clip clip--
Hi.
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.
However I'm a little puzzled...
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.
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.
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.
Please give me your thoughts about this.
Kindly
//Marcus Herou
--clip clip--
I fixed this locally now by parsing the request body in the
HttpRequestHandler but it seems to be a very bad an non generic place to do
so.
Kindly
//Marcus
Re: Parsing http parameters
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-07-28 at 14:28 +0200, Marcus Herou wrote:
> 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
> :)
A utility class may also be an alternative. QueryStringParser?
> 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 ?
How about subclassing SocketHttp*Connection instead of
DefaultHttp*Connection? See the patch attached
> Looked at my code ?
>
Yes, I did. I would prefer a solution which would not require a new
parameter, though.
Oleg
> Kindly
>
> //Marcus
>
Re: Parsing http parameters
Posted by Marcus Herou <ma...@gmail.com>.
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 <ol...@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 <os...@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
>
>
Re: Parsing http parameters
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <os...@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
Re: Parsing http parameters
Posted by Marcus Herou <ma...@gmail.com>.
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 ?
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...
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 <os...@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
>
>
Re: Parsing http parameters
Posted by Roland Weber <os...@dubioso.net>.
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