tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [RFC] Handling the '*' URL
Date Fri, 11 Jul 2003 07:37:49 GMT

----- Original Message -----
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Thursday, July 10, 2003 11:29 PM
Subject: Re: [RFC] Handling the '*' URL


> Bill Barker wrote:
> > This is really a Request-For-Comments, I'm not proposing anything.  I'm
> > looking into resolving Bug #21454.
> >
> > At the moment, requests for e.g:
> >   OPTIONS * HTTP/1.1
> >   TRACE * HTTP/1.1
> > get properly handled by TC 5 (thanks to Keith's patch), buy passing them
to
> > DefaultServlet.  However, the '*' URL is really a HTTP Protocol URL, so
it
> > seems to me that it really should be handled by the Connector instead of
the
> > Servlet.  On the other hand, we have access to the rich Servlet-API
> > implementations (Ok, so I don't in 3.3-land, but I can fake it ;-).  So
my
> > problem is that I can't see the correct route to go here.
> >
> > Opinions?
>
> I'm only talking about OPTIONS here. TRACE is protocol specific for all
> URLs (but I don't care about it ;-) ).
>
> I think it should be handled by the servlet, because for example you can
> replace the default servlet by the WebDAV servlet, and then it should
> return the DAV methods.
>

At the moment (at least in TC 5, which is the only one that returns a 200
Response), this is handled by the Default-Servlet (which ever one is mapped
to '/', which defaults to DefaultServlet) in the ROOT Context.  So, the
current response according to you is still wrong if I have the the 'webdav'
Context installed.

<rfc-quote rfc="2616" section="9.2">
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
apply to the server in general rather than to a specific resource. Since a
server's communication options typically depend on the resource, the "*"
request is only useful as a "ping" or "no-op" type of method; it does
nothing beyond allowing the client to test the capabilities of the server.
For example, this can be used to test a proxy for HTTP/1.1 compliance (or la
ck thereof).
</rfc-quote>

I'm starting to lean to putting this into the Connector, rather than sending
it to the Servlet (who can't possibly give a server-wide answer).  Note:
I'm only interested in the case where the Request-URI.equals("*").  All
other cases will go to the Servlet.


> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message