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/07/29 22:09:52 UTC
[jira] Created: (HTTPCORE-107) tolerate SIP or other like-HTTP
message formats
tolerate SIP or other like-HTTP message formats
-----------------------------------------------
Key: HTTPCORE-107
URL: https://issues.apache.org/jira/browse/HTTPCORE-107
Project: HttpComponents Core
Issue Type: Improvement
Affects Versions: 4.0-alpha5
Reporter: Roland Weber
Fix For: 4.0-alpha6
The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
- HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
- HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber resolved HTTPCORE-107.
-----------------------------------
Resolution: Fixed
I'm through with the changes. Now I'll have to hack up some contrib code to make sure that things work as expected.
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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] Assigned: (HTTPCORE-107) tolerate SIP or other like-HTTP
message formats
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber reassigned HTTPCORE-107:
-------------------------------------
Assignee: Roland Weber
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524379 ]
Oleg Kalnichevski commented on HTTPCORE-107:
--------------------------------------------
> There are some dirty details that prevent ProtocolVersion from being a Comparable
Why not just drop Comparable at all?
Oleg
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525924 ]
Roland Weber commented on HTTPCORE-107:
---------------------------------------
I've changed the uses of HttpVersion to ProtocolVersion wherever appropriate. The former getHttpVersion in HttpMessage and related is renamed to getProtocolVersion. If you prefer getVersion instead, please change it. That's one of the cases where Eclipse really shines :-)
There's one more thing to do: change BasicLineParser to be configurable with a ProtocolVersion for the protocol name.
cheers,
Roland
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber updated HTTPCORE-107:
----------------------------------
Attachment: 2k7-09-01-sip-1.txt
Here's step 1 towards SIP tolerance. (I don't have time for a complete patch today.)
HttpVersion gets a new base class ProtocolVersion which has the protocol name in addition to the version. There are some dirty details that prevent ProtocolVersion from being a Comparable, but it does have version comparison methods.
The other changes in the patch replace checks for (>= HTTP/1.1) with !(<= HTTP/1.0). That's because SIP/2.0 is neither, and the default for an uncomparable protocol version should be the HTTP/1.1 behavior.
What's missing from the patch is the dirty work:
- replace getHttpVersion with getProtocolVersion in RequestLine, StatusLine (or just getVersion?)
- replace HttpVersion with ProtocolVersion in LineParser, LineFormatter
then fix all the dependent classes.
I think it's worth the effort, and I'd take care of it.
cheers,
Roland
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525912 ]
Roland Weber commented on HTTPCORE-107:
---------------------------------------
I'm fine with that. Is it OK if I commit the patch minus Comparable and switch to commit-then-review mode for the rest of the changes?
cheers,
Roland
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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-107) tolerate SIP or other like-HTTP
message formats
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525914 ]
Oleg Kalnichevski commented on HTTPCORE-107:
--------------------------------------------
Sure. Hack away.
Oleg
> tolerate SIP or other like-HTTP message formats
> -----------------------------------------------
>
> Key: HTTPCORE-107
> URL: https://issues.apache.org/jira/browse/HTTPCORE-107
> Project: HttpComponents Core
> Issue Type: Improvement
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Fix For: 4.0-alpha6
>
> Attachments: 2k7-09-01-sip-1.txt
>
>
> The Session Initiation Protocol in RFC 3261 defines a message format which is structurally identical to HTTP/1.1 (http://tools.ietf.org/html/rfc3261#section-7). The only difference is that the protocol name used in the request and response lines is SIP instead of HTTP, and the version number is 2.0. HttpCore should be able to handle these messages, or others with alternative protocol names but identical syntactic structures. There are two parts of core affected:
> - HttpVersion currently stores only the version number, but uses a hard-coded protocol name HTTP
> - HTTP message parsing checks for a hard-coded protocol name HTTP (both core and NIO)
> Note that this is "tolerance for" and not "support of" SIP. SIP makes heavy use of intermediate 1xx responses, for which our HttpRequestExecutor and HttpService classes are not prepared. The rest of the core/main module, including message representation, connections, and the params and interceptor frameworks, could be used for SIP or other alternative protocols without further changes.
> This is a change of medium complexity which would significantly improve the flexibility of the HttpCore module.
--
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