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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
