Re: [RFC] Handling the '*' URL
Well, it seems that the consensus is for the default servlet. That's where I'll make the changes for 3.3. - Original Message - From: "Keith Wannamaker" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, July 11, 2003 5:35 AM Subject: RE: [RFC] Handling the '*' URL > Hi Bill, I am partial to handling it in the default servlet. > I agree the root context can't speak definitively for all > contexts, but I think it has a better chance of knowing a > proper response than the connector. > > Keith > > | -Original Message- > | From: Bill Barker [mailto:[EMAIL PROTECTED] > | Sent: Friday, July 11, 2003 2:08 AM > | To: Tomcat Developers List > | Subject: [RFC] Handling the '*' URL > | > | > | 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? > | > | > | - > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > | > | > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RFC] Handling the '*' URL
Hi Bill, I am partial to handling it in the default servlet. I agree the root context can't speak definitively for all contexts, but I think it has a better chance of knowing a proper response than the connector. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED] | Sent: Friday, July 11, 2003 2:08 AM | To: Tomcat Developers List | Subject: [RFC] Handling the '*' URL | | | 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? | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Handling the '*' URL
Bill Barker wrote:
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
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.
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).
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.
In my reasoning, I was implying that I had the asumption that the
default servlet of the root context was a fair representation of what
the server could do.
Both work for me :)
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Handling the '*' URL
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
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.
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).
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
