You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Nels N. Nelson (JIRA)" <ji...@apache.org> on 2007/07/20 19:37:06 UTC
[jira] Created: (HTTPCORE-104) Handler Registry Should Match Using
Regular Expressions
Handler Registry Should Match Using Regular Expressions
-------------------------------------------------------
Key: HTTPCORE-104
URL: https://issues.apache.org/jira/browse/HTTPCORE-104
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.0-alpha5, 4.0-alpha4, 4.0-alpha6, 4.0-beta1, 4.0-rc1
Reporter: Nels N. Nelson
Fix For: 4.0-alpha6, 4.0-beta1, 4.0-rc1
Hello!
In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
This method is better and provides more flexibility to developers trying to add new Handlers:
<code>
protected boolean matchUriRequestPattern(final String pattern,
final URI requestUri)
{
try {
String path = requestUri.getPath();
Pattern p = Pattern.compile(pattern);
Matcher matcher = p.matcher(path);
return matcher.matches();
}
catch (java.util.regex.PatternSyntaxException ex) {
return false;
}
}
</code>
These changes would make this code far more accurate:
<code>
protected void doService(
final HttpRequest request,
final HttpResponse response,
final HttpContext context) throws HttpException, IOException {
HttpRequestHandler handler = null;
if (this.handlerResolver != null) {
URI requestURI = request.getRequestLine().getUri();
handler = this.handlerResolver.lookup(requestURI);
}
if (handler != null) {
handler.handle(request, response, context);
} else {
response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
}
}
</code>
These changes would allow developers to add new custom handlers in this way:
<code>
String pattern = ".*\\.extension";
HttpRequestHandler handler = new HttpServletHandler(...);
HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
reqistry.register(pattern, handler);
</code>
Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
<code>
public interface RequestLine {
String getMethod();
HttpVersion getHttpVersion();
URI getUri();
}
</code>
Thanks for your attention to this issue.
-Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Nels N. Nelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514778 ]
Nels N. Nelson commented on HTTPCORE-104:
-----------------------------------------
Hello Oleg, Roland,
Thanks for your time with this issue.
I too would indeed like to be able to make my app be portable to the Java ME platform. I know of at least one "competing" application in particular that is compatible with 1.3, which is why I planned to make my project also be portable to 1.3. I was not going to refactor my project to work with 1.3 until much later, but since the changes I suggested will *never* be implemented, and for good reasons, it seems prudent to refactor my project right away.
I am currently researching query string handling techniques that meet this portability requirement, but I would prefer to use any code that already exists in, or is based on, or is related to, the httpcore project. Do you happen to know of anything like that already?
-Nels
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514784 ]
Oleg Kalnichevski commented on HTTPCORE-104:
--------------------------------------------
Hello Nels,
You may want to take a look at Commons Codec [1]. It will not give you a complete solution, as you would still have to parse request query into an array of name/value pairs by yourself, but at least you could make use of URLCodec to decode values.
Oleg
[1] http://jakarta.apache.org/commons/codec/
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Nels N. Nelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514717 ]
Nels N. Nelson commented on HTTPCORE-104:
-----------------------------------------
(Hrm, let me finish this sentence: This has caused me to realign) the requirements of the project for which I am using httpcore as a base.
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Nels N. Nelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514714 ]
Nels N. Nelson commented on HTTPCORE-104:
-----------------------------------------
Roland,
Thanks for your response. I see your points, and I agree with you. This has caused me to realign
May I ask, can you recommend any 1.3-compatible code for handling the query strings of plain old string literal uris? I do not see any existing code for such functionality in the httpcore codebase. I'm guessing I'll have to write my own, or co-opt some open source library, but I'd like to see if I can keep my current project as close to the requirements of the httpcore project requirements as possible.
-Nels
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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] Closed: (HTTPCORE-104) Handler Registry Should Match Using
Regular Expressions
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber closed HTTPCORE-104.
---------------------------------
Resolution: Won't Fix
Hello Nels,
your suggestions share one fault:
- regular expressions are Java 1.4
- class URI is Java 1.4
whereas
- core module-main is Java 1.3
HttpRequestHandlerRegistry is really just the default implementation of interface HttpRequestHandlerResolver, you are of course welcome to have a different implementation of that interface, using newer Java versions. If you feel like contributing it, we'd be happy to include it in our contrib code.
A request implementation class that keeps an instance of URI is available in HttpClient as of alpha1, which has just been released. Unlike core module-main, HttpClient requires Java 1.4 and can therefore use the URI class.
http://jakarta.apache.org/httpcomponents/httpcomponents-client/httpclient/apidocs/org/apache/http/client/methods/HttpUriRequest.html
cheers,
Roland
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6, 4.0-beta1, 4.0-rc1
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514747 ]
Oleg Kalnichevski commented on HTTPCORE-104:
--------------------------------------------
Nels,
The only reason we want to retain 1.3 compatibility for HttpCore is to keep it portable to the Java ME platform. If you are targeting JSE or JEE platforms I personally see no reason for not using Java 1.4 or newer.
Oleg
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match Using
Regular Expressions
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber updated HTTPCORE-104:
----------------------------------
Fix Version/s: (was: 4.0-beta1)
(was: 4.0-rc1)
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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-104) Handler Registry Should Match
Using Regular Expressions
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514731 ]
Roland Weber commented on HTTPCORE-104:
---------------------------------------
Hello Nels,
I don't think you should bother with Java 1.3 compatibility in your application, unless you have to. We just make sure that the _source_ of HttpCore/main compiles and tests against Java 1.3. Even the binary releases we ship are built with Java 1.4 and not tested against 1.3. If anyone has a need to use core in a Java 1.3 environment, they are supposed to compile the sources themselves. As soon as you use something besides the core, you'll inherit a 1.4 dependency anyway.
Please, do make use of Java 1.4 features. We also love to use them, anywhere but in core. Implement your own handler and request class using 1.4, that's what we want you to do. Core is meant to be used as a framework where you plug in what you need, making use of features available in your application's target environment. We just can't accept such contributions into the core itself, because we don't want to impose tougher requirements on other people's applications.
cheers,
Roland
> Handler Registry Should Match Using Regular Expressions
> -------------------------------------------------------
>
> Key: HTTPCORE-104
> URL: https://issues.apache.org/jira/browse/HTTPCORE-104
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha4, 4.0-alpha5, 4.0-alpha6, 4.0-beta1, 4.0-rc1
> Reporter: Nels N. Nelson
> Fix For: 4.0-alpha6
>
>
> Hello!
> In HttpRequestHandlerRegistry, the method matchUriRequestPattern(final String pattern, final String requestUri) uses what is, in my opinion, a poor strategy for pattern matching.
> This method is better and provides more flexibility to developers trying to add new Handlers:
> <code>
> protected boolean matchUriRequestPattern(final String pattern,
> final URI requestUri)
> {
> try {
> String path = requestUri.getPath();
> Pattern p = Pattern.compile(pattern);
> Matcher matcher = p.matcher(path);
> return matcher.matches();
> }
> catch (java.util.regex.PatternSyntaxException ex) {
> return false;
> }
> }
> </code>
> These changes would make this code far more accurate:
> <code>
> protected void doService(
> final HttpRequest request,
> final HttpResponse response,
> final HttpContext context) throws HttpException, IOException {
> HttpRequestHandler handler = null;
> if (this.handlerResolver != null) {
> URI requestURI = request.getRequestLine().getUri();
> handler = this.handlerResolver.lookup(requestURI);
> }
> if (handler != null) {
> handler.handle(request, response, context);
> } else {
> response.setStatusCode(HttpStatus.SC_NOT_IMPLEMENTED);
> }
> }
> </code>
> These changes would allow developers to add new custom handlers in this way:
> <code>
> String pattern = ".*\\.extension";
> HttpRequestHandler handler = new HttpServletHandler(...);
> HttpRequestHandlerRegistry reqistry = new HttpRequestHandlerRegistry();
> reqistry.register(pattern, handler);
> </code>
> Currently, my version of the HttpComponents core software uses <code>URI</code> to represent the <code>requestURI</code> parameter throughout the code. This has provided greater convenience, error handling (in the instantiation of the <code>BasicRequestLine</code> class, for instance), and flexibility of extension. I can enumerate the specifics on this, if necessary, but I believe that would be a discussion for a separate Jira Issue, which I will happily create, if I am convinced that its priority would be at least major, which currently, I am not. Such a change would cause several changes throughout multiple classes, stemming from changes to the <code>RequestLine</code> interface as follows:
> <code>
> public interface RequestLine {
> String getMethod();
> HttpVersion getHttpVersion();
> URI getUri();
>
> }
> </code>
> Thanks for your attention to this issue.
> -Nels
--
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