You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2007/08/20 17:51:36 UTC
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521123 ]
Oleg Kalnichevski commented on HTTPCORE-110:
--------------------------------------------
Roland,
Could you please avoid using RuntimeException in the interface declarations and either use a specific type or none at all? Declaring RuntimeException in the throws clause is like saying "shit happens". Otherwise I can live with the patch
Oleg
> refactor message parsing and formatting, step 2
> -----------------------------------------------
>
> Key: HTTPCORE-110
> URL: https://issues.apache.org/jira/browse/HTTPCORE-110
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-08-20-parser-1.txt
>
>
> The line-level parsing and formatting for HTTP messages is spread across static helper methods in o.a.h.message. Refactor the code to allow for easy replacement of these parser and formatter elements, which are used by both core and NIO.
> Ideally, handling of header continuation lines, which is currently still implemented in specific parsers for blocking and NIO, could be factored out too. That would require a stateful parser.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-08-21 at 08:08 +0200, Roland Weber wrote:
> Oleg Kalnichevski (JIRA) wrote:
> > Could you please avoid using RuntimeException in the interface declarations
> > and either use a specific type or none at all? Declaring RuntimeException
> > in the throws clause is like saying "shit happens".
>
> No problem. I was caught by surprise at that point, because the
> parsers for request and status line would throw a ProtocolException
> on parse errors, whereas the parsers for headers would throw a
> RuntimeException. Declaring the RuntimeException was the quickest
> hack to document how parse errors are reported.
>
> I'll change the parsers, including the constructor of BufferedHeader,
> to throw a ProtocolException instead. That will also show up in
> Header.getElements(), which probably affects the cookie code.
>
> Btw, is it intentional that both implementations of Header.getElements
> will repeat the parsing for each invocation instead of caching the
> result?
>
Yes, this is intentional. It is a trade-off between caching data that
may never be used and repeating the parsing run in case the header
value / elements are accessed more than once. In my opinion the former
is way more frequent.
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
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski wrote:
> Could you please consider changing LineParser to throw ParseException
> and re-throwing ParseException as ProtocolException in the protocol
> layer?
I'll have a look at how much exception mapping that will require.
Not today though.
> What are your plans about the formatting code?
Basically the same exercise: move static code into formatter classes
with a default instance. It will probably occupy me through next week.
I want to finish the parser refactoring first, at least the big parts.
The two new interfaces are not everything yet.
I'll complete the removal of static parsing code today and target the
next step on Thursday. Tomorrow I'm offline, friends come to visit.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Roland Weber <os...@dubioso.net>.
Roland Weber wrote:
> Oleg Kalnichevski wrote:
>> Could you please consider changing LineParser to throw ParseException
>> and re-throwing ParseException as ProtocolException in the protocol
>> layer?
>
> I'll take care of it.
Done.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski wrote:
> Could you please consider changing LineParser to throw ParseException
> and re-throwing ParseException as ProtocolException in the protocol
> layer?
The re-throwing needs to be implemented in four places:
- io::AbstractMessageParser.parse
- nio::AbstractMessageParser.parse
- io::ChunkedInputStream.parseTrailerHeaders
- nio::ChunkDecoder.processFooters
I'll take care of it.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-08-21 at 09:50 +0200, Roland Weber wrote:
> Roland Weber wrote:
> > I'll change the parsers, including the constructor of BufferedHeader,
> > to throw a ProtocolException instead. That will also show up in
> > Header.getElements(), which probably affects the cookie code.
>
> I had to give up on that idea. Cookie and Auth create BufferedHeader
> from data they generated. It would have been a lot of effort to no avail.
> I've defined an unchecked ParseException instead, so that it is no
> longer necessary to map InvalidArgumentException to ProtocolException
> when the check in BufferedHeader.<cons> is actually relevant. The
> parser code for header values doesn't check for parse errors anyway.
>
> cheers,
> Roland
>
Roland,
Could you please consider changing LineParser to throw ParseException
and re-throwing ParseException as ProtocolException in the protocol
layer?
What are your plans about the formatting code?
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: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Roland Weber <os...@dubioso.net>.
Roland Weber wrote:
> I'll change the parsers, including the constructor of BufferedHeader,
> to throw a ProtocolException instead. That will also show up in
> Header.getElements(), which probably affects the cookie code.
I had to give up on that idea. Cookie and Auth create BufferedHeader
from data they generated. It would have been a lot of effort to no avail.
I've defined an unchecked ParseException instead, so that it is no
longer necessary to map InvalidArgumentException to ProtocolException
when the check in BufferedHeader.<cons> is actually relevant. The
parser code for header values doesn't check for parse errors anyway.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by Roland Weber <os...@dubioso.net>.
Oleg Kalnichevski (JIRA) wrote:
> Could you please avoid using RuntimeException in the interface declarations
> and either use a specific type or none at all? Declaring RuntimeException
> in the throws clause is like saying "shit happens".
No problem. I was caught by surprise at that point, because the
parsers for request and status line would throw a ProtocolException
on parse errors, whereas the parsers for headers would throw a
RuntimeException. Declaring the RuntimeException was the quickest
hack to document how parse errors are reported.
I'll change the parsers, including the constructor of BufferedHeader,
to throw a ProtocolException instead. That will also show up in
Header.getElements(), which probably affects the cookie code.
Btw, is it intentional that both implementations of Header.getElements
will repeat the parsing for each invocation instead of caching the
result?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org