You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <os...@dubioso.net> on 2007/07/27 16:40:00 UTC
[HttpCore] HTTP parser
Hi all,
a recent communication on the user list made me aware
that we have classes Http*Parser in HttpNIO, but not in
HttpCore for the traditional IO. There, the logic is
implemented directly in the connections. I like the
structure of NIO better.
We get inquiries about tolerating bad HTTP messages on a
regular basis. Having a parser interface with a default
implementation that can be substituted would make things
easier for those users.
What do you think?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HTTP parser
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-07-27 at 17:33 +0200, Roland Weber wrote:
> Oleg Kalnichevski wrote:
> > In both cases one still needs to subclass abstract connection classes in
> > order to customize the way HTTP messages are constructed.
> >
> > I can take care of ensuring class name consistency across modules this
> > weekend.
>
> OK. But I still feel it would be a good idea to factor out
> the message header parsing from AbstractClientConnection
> and, for sake of symmetry, AbstractServerConnection.
> It would also serve people such as Jeroen, who would then
> no longer need to create a fake connection in order to
> parse data that is already in memory.
>
> cheers,
> Roland
>
Makes sense. I'll take care of that.
Oleg
>
> ---------------------------------------------------------------------
> 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: [HttpCore] HTTP parser
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski wrote:
> In both cases one still needs to subclass abstract connection classes in
> order to customize the way HTTP messages are constructed.
>
> I can take care of ensuring class name consistency across modules this
> weekend.
OK. But I still feel it would be a good idea to factor out
the message header parsing from AbstractClientConnection
and, for sake of symmetry, AbstractServerConnection.
It would also serve people such as Jeroen, who would then
no longer need to create a fake connection in order to
parse data that is already in memory.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HTTP parser
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-07-27 at 16:40 +0200, Roland Weber wrote:
> Hi all,
>
> a recent communication on the user list made me aware
> that we have classes Http*Parser in HttpNIO, but not in
> HttpCore for the traditional IO. There, the logic is
> implemented directly in the connections. I like the
> structure of NIO better.
> We get inquiries about tolerating bad HTTP messages on a
> regular basis. Having a parser interface with a default
> implementation that can be substituted would make things
> easier for those users.
>
> What do you think?
>
Roland,
Please note the job parsing HTTP lines is taken care of by
SessionInputBuffer / SessionOutputBuffer classes Core NIO, not by the
HttpMessageParser. SessionInputBuffer and SessionOutputBuffer classes
are direct equivalents of AbstractHttpDataReceiver and
AbstractHttpDataTransmitter in Core Base. So, it all boils down to
inconsistent class names in HttpCore Base and HttpCore NIO.
In both cases one still needs to subclass abstract connection classes in
order to customize the way HTTP messages are constructed.
I can take care of ensuring class name consistency across modules this
weekend.
Oleg
> cheers,
> 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