date:20030320

Re: [4.1.23] Deprecating mod_webapp

2003-03-20 Thread Henri Gomez

George Sexton wrote:
From a purely practical standpoint, that would be terribly complicated.
Mod_webapp would have to read and fully understand the web.xml and all of
the servlet mappings. This is made even more impossible by the addition of
filters to the Servlet API. How can mod_webapp even begin to guess at the
hidden logic contained within a filter? It is totally impossible. It's not
clear to me that you could feasibly implement this kind of front end and
incur less overhead that simply passing the request to the servlet engine.
Even if you could, at the end of the day, it would still be non-compliant
because the last sentence of the second paragraph of section 3.1 of the
Servlet API 2.3 Spec says:
all requests that begin with the /catalog request path, known as the
context path, are routed to the web application associated with the servlet
context.
I quoted this exact spec to a client because they wanted to do what you
propose, only their engine is not smart enough to parse the web.xml. they
wanted me to rename all of my pages to end in .jsp so that it would get
forwarded.
To be compliant, the spec must be fulfilled. ALL requests for the context
path must be forwarded to the application. To do otherwise is not compliant
with the spec. A specification is like a map through a mine field. You must
do precisely what it says, without expansion, or interpolation. If you do
otherwise, you will at the least blow your foot off. In our case, by
scrupulously following the spec, we have an application that has been tested
on 6-8 servlet engines with only one small tweak to work around a bug in one
of them.
Deviation from the specification, even in the name of imagined efficiency is
not acceptable. This is particularly true of Tomcat since it has the role of
Reference Implementation.
From my experience JkMount directice of mod_jk is simpler to use in real
environment when you want to split load between Apache and Tomcat, one
handling static/php and the other servlet/jsp.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Digest Authentication

2003-03-20 Thread carlos.quiroz-castro

Hi all

I've been trying unsuccessfully to use the Digest authentication in Tomcat with my 
webapp. I need it because Basic authentication is too weak and I cannot use SSL on the 
client side.

I noticed that the implementation in Tomcat has some problems that I describe below:

1. In org.apache.catalina.realm.RealmBase it is said that it implements RFC 2069 but 
IMHO it actually implements partially RFC 2617 since it uses the qop option to 
calculate the digests, which first appeared in RFC 2617

2. RFC 2617 clearly says that if qop is not present the request-digest should be 
calculated as in RFC 2069. However in the current implementation it is always 
calculated as RFC 2617, i.e.

String serverDigestValue = md5a1 + : + nOnce + : + nc + :
+ cnonce + : + qop + : + md5a2;

This excludes the possibility of qop being null in which case the serverDigestValue 
should be

String serverDigestValue = md5a1 + : + nOnce + : + md5a2;

Also the case of qop being auth-int is not taken into account at all

3. Finally, there is a problem when obtaining the values qop and nc. Some browsers 
send qop with quotes, for instance IE, but Mozilla sends them without quotes. Same 
with nc. 

What happens is that in org.apache.catalina.authenticator.DigestAuthenticator the qop 
is calculated always removing the quotes. That makes that in a mozilla's request 
qop=auth becomes qop=ut and the Digest calculation is different. I'm not sure what 
should be the right thing to do since clearly both cases may happen. Should they both 
be supported or should Tomcat be able to analyze the values and accept both? I don't 
know if Tomcat has some policy about being able to accept bogus input

BR

Carlos Quiroz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Digest Authentication

2003-03-20 Thread Remy Maucherat

[EMAIL PROTECTED] wrote:
Hi all

I've been trying unsuccessfully to use the Digest authentication in Tomcat with my webapp. I need it because Basic authentication is too weak and I cannot use SSL on the client side.

I noticed that the implementation in Tomcat has some problems that I describe below:

1. In org.apache.catalina.realm.RealmBase it is said that it implements RFC 2069 but IMHO it actually implements partially RFC 2617 since it uses the qop option to calculate the digests, which first appeared in RFC 2617

2. RFC 2617 clearly says that if qop is not present the request-digest should be calculated as in RFC 2069. However in the current implementation it is always calculated as RFC 2617, i.e.

String serverDigestValue = md5a1 + : + nOnce + : + nc + :
+ cnonce + : + qop + : + md5a2;
This excludes the possibility of qop being null in which case the serverDigestValue should be

String serverDigestValue = md5a1 + : + nOnce + : + md5a2;

Also the case of qop being auth-int is not taken into account at all

3. Finally, there is a problem when obtaining the values qop and nc. Some browsers send qop with quotes, for instance IE, but Mozilla sends them without quotes. Same with nc.

What happens is that in org.apache.catalina.authenticator.DigestAuthenticator the qop is calculated always removing the quotes. That makes that in a mozilla's request qop=auth becomes qop=ut and the Digest calculation is different. I'm not sure what should be the right thing to do since clearly both cases may happen. Should they both be supported or should Tomcat be able to analyze the values and accept both? I don't know if Tomcat has some policy about being able to accept bogus input
I recommend you prepare a patch for this. I'm pretty sure you know about
that already, but DIGEST will not work with most Tomcat realms (a
refactoring is needed, and will hopefully occur in Tomcat 5).

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [4.1.23] Deprecating mod_webapp

2003-03-20 Thread Endre Stølsvik

On Wed, 19 Mar 2003, George Sexton wrote:

| From a purely practical standpoint, that would be terribly complicated.
| Mod_webapp would have to read and fully understand the web.xml and all of
| the servlet mappings. This is made even more impossible by the addition of
| filters to the Servlet API.

Impossible?!?

| How can mod_webapp even begin to guess at the hidden logic contained
| within a filter?

Well, it would have to forward requests that were filtered, OF COURSE,
since that includes bytecode.

| It is totally impossible. It's not clear to me that you could feasibly
| implement this kind of front end and incur less overhead that simply
| passing the request to the servlet engine. Even if you could, at the end
| of the day, it would still be non-compliant because the last sentence of
| the second paragraph of section 3.1 of the Servlet API 2.3 Spec says:
|
| all requests that begin with the /catalog request path, known as the
| context path, are routed to the web application associated with the servlet
| context.

Read: web application. Not Servlet Container.

If you absorb the fact that Apache and Tomcat would _work together_
combining forces as being the Servlet Container, then the above
statement would hold true.

One does encryption (read: SSL) on the Apache side, even though you have
to forward parts of that to Tomcat. This is just as deviant from the
specs you're referring to, as, considering the web.xml, apache serves
static files himself, not bothering his java-executing part of the
(combined) Servlet Container to do this..

|
| I quoted this exact spec to a client because they wanted to do what you
| propose, only their engine is not smart enough to parse the web.xml. they
| wanted me to rename all of my pages to end in .jsp so that it would get
| forwarded.

What's the idea here?!

|
| To be compliant, the spec must be fulfilled. ALL requests for the context
| path must be forwarded to the application.

Read again: THE APPLICATION. Right. Running in the Servlet Container.
WHICH IS the Apache+Tomcat COMBINATION when you run it with mod_WHATEVER
inside of Apache.

How would you interpret a Servlet Container that was coded exclusively in
C++, not having any normal JVM, simly acting as the VM itself by
interpreting bytecode? And then, what if you split these thing slightly
apart, using a (standard) JVM to execute the bytecode? And then, having
the JVM run standalone, using a communication channel of some sort to make
it run the bytecodes? .. And then, finally, thought; what the hell, lets
just use Apache and Tomcat instead??

| To do otherwise is not compliant with the spec. A specification is like
| a map through a mine field. You must do precisely what it says, without
| expansion, or interpolation.

Thanks for elaborating on spec. interpretation.


-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [4.1.23] Deprecating mod_webapp

2003-03-20 Thread jean-frederic clere

Remy Maucherat wrote:
Hi,

I'd like to officially deprecate mod_webapp in Tomcat 4.1.23.
+1 :-((
I am using jk2 in 2 FSC products so I prefer that the energies go to one 
connector instead beeing spread in severals.

It is no longer maintained, and will not work with Tomcat 5.0 (at least 
it won't unless people contribute stuff).
That is something I will not make alone because I have _very_ little free time 
for the next mounths.


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]

[VOTE] [4.1.24] Stability rating

2003-03-20 Thread Remy Maucherat

ballot
[ ] Alpha
[ ] Beta
[ ] Stable (GA)
/ballot
Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

65 matches

Mail list logo