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 (JIRA)" <ji...@apache.org> on 2007/08/19 10:45:30 UTC
[jira] Created: (HTTPCORE-110) refactor message parsing and
formatting, step 2
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
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
[jira] Resolved: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber resolved HTTPCORE-110.
-----------------------------------
Resolution: Fixed
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522848 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
Interface HeaderValueFormatter with default implementation is the companion to HeaderValueParser.
I found where the code is used ;-)
> 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, 2k7-08-23-parser-2.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
[jira] Updated: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber updated HTTPCORE-110:
----------------------------------
Attachment: 2k7-08-23-parser-2.txt
Here's the next step. The header section parsing has been moved into a separate class, which is stateful. The class basically encapsulates the parsing logic found in nio.AbstractMessageParser. With respect to object creations, for blocking IO the change should be neutral for the message head and add one object per footer section being received.
The same interface and class can be used for NIO in AbstractMessageParser and ChunkedInput, where it would add one object creation per message and footer, respectively. The logic there is a bit intricate though, I would prefer not to change it myself.
If I hear no complains by tomorrow evening (CET), I will commit this patch and proceed with subsequent cleanup.
cheers,
Roland
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525911 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
Hi Oleg,
thanks. I see your point with the init method, that was a mistake on my part. I thought the parser and formatter would be created per message and pick up the new line parser/formatter on that occasion. I'll drop the attributes along with getters and setters from core. No need for extra factory methods, the createRe*Parser and createRe*Writer methods are easy enough to override. They are already consistent with NIO.
No need to revisit the header continuation discussion. It is just a minor issue in my strive for perfection, and I wouldn't have time to work on it anyway.
cheers,
Roland
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522203 ]
Oleg Kalnichevski commented on HTTPCORE-110:
--------------------------------------------
Roland, what's the POINT of doing this? Please do not commit. Regards from Budapest. 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, 2k7-08-23-parser-2.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
[jira] Updated: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber updated HTTPCORE-110:
----------------------------------
Attachment: 2k7-08-20-parser-1.txt
Here's a first step that should allow to form an opinion on my approach. Various static parse methods are moved to two dedicated classes. The old static code is still in there, and I've hacked in some places to avoid more excessive changes before review. In particular, the footer processing in ChunkedInputStream still calls a static method. The header continuation line parsing is not addressed by this patch. Parameterization of connections is also not addressed, the default instances of the new parser classes are used.
I believe that this design does not produce more garbage than the static version. I would prefer linear parsing based on a class or interface like java.text.ParsePosition instead of the toIndex currently used, but that is a separate issue.
Please let me know what you think.
cheers,
Roland
> 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
[jira] Issue Comment Edited: (HTTPCORE-110) refactor message
parsing and formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522741 ]
rolandw edited comment on HTTPCORE-110 at 8/26/07 10:11 AM:
-----------------------------------------------------------------
Actually, I am trying to define a complete interface for the parsing code that I set out to refactor. Right now, part of the parsing still needs to be done outside of the new interfaces. But that is not essential to HTTPCORE-107, so we can drop the last step.
I'll work on the formatting code. We'll have to see whether I can finish until you're back.
cheers,
Roland
was (Author: rolandw):
Actually, I am trying to define a complete interface for the parsing code that I set out to refactor. Right now, part of the parsing still needs to be done outside of the new interfaces. But that is not essential to HTTPCORE-110, so we can drop the last step.
I'll work on the formatting code. We'll have to see whether I can finish until you're back.
cheers,
Roland
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524337 ]
Oleg Kalnichevski commented on HTTPCORE-110:
--------------------------------------------
Hi Roland
I reviewed the changed and I think this is a job well done. The only issue I have is that lineParser and lineFormatter setters in AbstractHttpClient/ServerConnection take no effect once the connection has been initialized. I find this kind of nasty and think the problem needs fixing. We should either make sure lineParser and lineFormatter get propagated to the existing message parser and formatter when changed with the setter or replace the setters with a factory method (requires subclassing but consistent with the rest of the code). I tend to prefer the latter approach. We should also provide a consistent mechanism to override lineParser and lineFormatter in the NIO connection classes.
Oleg
PS: Do you think we need to revisit the header continuation parsing discussion?
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522758 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
Interface LineFormatter with default implementation is the companion to LineParser.
Next work item is an interface HeaderValueFormatter and default implementation for hosting the formatting code in HeaderElement and NameValuePair. That code seems to be currently unused, at least within the framework.
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522741 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
Actually, I am trying to define a complete interface for the parsing code that I set out to refactor. Right now, part of the parsing still needs to be done outside of the new interfaces. But that is not essential to HTTPCORE-110, so we can drop the last step.
I'll work on the formatting code. We'll have to see whether I can finish until you're back.
cheers,
Roland
> 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, 2k7-08-23-parser-2.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>.
Roland Weber wrote:
> Oleg Kalnichevski (JIRA) wrote:
>
>> Why would _anyone_ _ever_ want a different implementation
>> of the header continuation parsing?
>>
>
> Because they are asked to implement a proxy that maintains
> header continuation line breaks when forwarding headers?
>
>
What for? If people want to do something completely bizarre, I do not
see a point in going out of our way to help them
This patch adds an _unnecessary_ layer of complexity to a performance
critical execution path and buys us absolutely nothing.
Oleg
> Plug in a parser that inserts line breaks instead of spaces
> into the headers, and a header value parser that treats
> line breaks as whitespace. A formatter that recognizes
> line breaks is not needed if you use CRLF in the value.
>
> Making minimal changes to passing data is hardly a far-fetched
> requirement. There's also the variant "document everything
> that gets changed", followed by a sequence of "is that really
> necessary" discussions.
>
> 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 (JIRA) wrote:
> Why would _anyone_ _ever_ want a different implementation
> of the header continuation parsing?
Because they are asked to implement a proxy that maintains
header continuation line breaks when forwarding headers?
Plug in a parser that inserts line breaks instead of spaces
into the headers, and a header value parser that treats
line breaks as whitespace. A formatter that recognizes
line breaks is not needed if you use CRLF in the value.
Making minimal changes to passing data is hardly a far-fetched
requirement. There's also the variant "document everything
that gets changed", followed by a sequence of "is that really
necessary" discussions.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522738 ]
Oleg Kalnichevski commented on HTTPCORE-110:
--------------------------------------------
> if someone should have a need for that
This is _precisely_ my problem. Why would _anyone_ _ever_ want a different implementation of the header continuation parsing? Roland, you are trying to invent a wheel, which is more round than all others.
Could you please look into making symmetric changes to the message formatting code while I am away? We will revisit this issue once I am back.
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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522858 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
I've added lineParser and lineFormatter attributes to AbstractHttpClient/ServerConnection, along with getters and setters. Now it is possible to change the parser without subclassing a connection.
The same could be applied to NHttpConnectionBase, but I don't know whether that's the way you'd want to do it in NIO.
I'm through with the refactoring and will work on HTTPCORE-107 next.
cheers,
Roland
> 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, 2k7-08-23-parser-2.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
[jira] Commented: (HTTPCORE-110) refactor message parsing and
formatting, step 2
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522721 ]
Roland Weber commented on HTTPCORE-110:
---------------------------------------
The point is to properly encapsulate parsing logic currently replicated in three different places, in order to make the code better maintainable and to allow easy plugging in of alternative parse logic, if someone should have a need for that. With this change, the parsing logic becomes fully independent of the transport: traditional IO, NIO, email, files on disk, streams of logging data, or whatever. You write one piece of code that reads the message line by line and feeds it to the parser. The parser takes care of _all_ the parsing, and _only_ the parsing. Tests for that parser will be valid for all transports.
What is the point of having the header continuation parsing implemented in three different places?
cheers,
Roland
> 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, 2k7-08-23-parser-2.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