Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:
IE is still (unfortunately) the browser used by a lot of people, and if
there is a way to work around IE brokeness - I think it's a good idea to 
do it.

Complaining to M$ doesn't work - people will just end up buying IIS 
instead :-)

Seriously, not sure why is the veto invalid - if the choice is between 
Because the change is integrated in all 5.x stable releases, and because 
it is just too old. It should be plainly obvious.

having it working for 90% of the people and doing it 'right' - it is 
worth probably more discussion and a pragmatic decision :-) I would vote 
for fixing it for the 90% of people - at least until IE gets down to 
some 49%.
The issue obviously does not affect 90% of people (if it was, we'd have 
more than a few people complaining, it should be obvious ...), as the IE 
bug is a specific situation, unlike what Keith's FUD would want to show. 
However, it used to completely break Mozilla under SSL (as a compromise, 
I asked for Keith to show good faith and test it again, but all he 
seemed to be interested in is least effort in getting his patch in).

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Costin Manolache]

Remy Maucherat wrote:
Keith Wannamaker wrote:
If no one else is concerned that Tomcat 5.5 doesn't work by default

Any other nonsensical statement to make ? The only thing that does not 
work is opening third party documents from the website, due to IE's 
broken handling of this.

How about a) going whining at M$ instead ? b) using appropriate 
configuration.

Your veto is completely invalid anyway.
IE is still (unfortunately) the browser used by a lot of people, and if
there is a way to work around IE brokeness - I think it's a good idea to 
do it.

Complaining to M$ doesn't work - people will just end up buying IIS 
instead :-)

Seriously, not sure why is the veto invalid - if the choice is between 
having it working for 90% of the people and doing it 'right' - it is 
worth probably more discussion and a pragmatic decision :-) I would vote 
for fixing it for the 90% of people - at least until IE gets down to 
some 49%.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

No one has commented so I withdraw my (valid) veto and I'll roll back
5.0 per Remy's wish.  I'm disappointed because I remember when Tomcat 
was an open-source project.

Keith
My veto of this change still stands, and it would be your responsibility 
of finding a fix more compatible with IE.  If no one else besides me 
thinks IE compatibility is important, head of tree is fine and I will 
withdraw my veto.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
If no one else weighs in on the root issue in a day or so, and you 
disagree with this change, I'll be happy to roll it back and/or backport 
5.5 head of tree in its place.
You can of course backport the changes from head, which add 
configurability without changing the behavior.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

If no one else weighs in on the root issue in a day or so, and you 
disagree with this change, I'll be happy to roll it back and/or backport 
5.5 head of tree in its place.

Keith
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:20:46
  Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to 
sending
  headers to disable caching.  This is well-intentioned but IE will 
not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.

Since we're on the subject, the 5.0.x branch is supposed to be stable. 
Changes which might break things are not a good idea.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:20:46
  Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to sending
  headers to disable caching.  This is well-intentioned but IE will not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.
Since we're on the subject, the 5.0.x branch is supposed to be stable. 
Changes which might break things are not a good idea.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
My veto of this change still stands, and it would be your responsibility 
of finding a fix more compatible with IE.  If no one else besides me 
thinks IE compatibility is important, head of tree is fine and I will 
withdraw my veto.
All right, I was wrong to offer a compromise, it seems. Back to my 
previous position then: your veto is clearly invalid.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

Remy Maucherat wrote:
Thanks. If you can find precisely what the issue with Mozilla was, and 
certify the behavior is now correct in Firefox (= no stupid caching with 
SSL), then you can indeed uncomment the isSecure here:

// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
//!request.isSecure() &&
My veto of this change still stands, and it would be your responsibility 
of finding a fix more compatible with IE.  If no one else besides me 
thinks IE compatibility is important, head of tree is fine and I will 
withdraw my veto.

Keith

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
keith   2005/04/19 07:06:24
  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  [34083, 27122, 28662, 29336, 29975, and 30618]
  - invert so that securePagesWithPragma secures the pages with Pragma
(retaining Remy's default behavior)
  
  To enable downloading of office docs with IE under SSL, add
  
  
   securePagesWithPragma="false" />
  
  to context.xml (with the appropriate authenticator class)
Thanks. If you can find precisely what the issue with Mozilla was, and 
certify the behavior is now correct in Firefox (= no stupid caching with 
SSL), then you can indeed uncomment the isSecure here:

// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
//!request.isSecure() &&
Don't remove the new field, which has a different behavior which might 
be of interest to some people.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
//this is the standard way to disable caching
Note that I don't want to only disable proxy caching, but also any 
client caching by default (this can be disabled easily if you feel it is 
not needed - for example, put the auth configuration in 
/META-INF/context.xml) for all security constrained pages (and esp 
confidential ones), so the comment is not right.

SSL should do that, except with Mozilla, which apparently did aggressive 
caching anyway unless told otherwise. Newer Mozilla and/or Firefox may 
or may not have changed this, this was long ago.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
If no one else is concerned that Tomcat 5.5 doesn't work by default
Any other nonsensical statement to make ? The only thing that does not 
work is opening third party documents from the website, due to IE's 
broken handling of this.

How about a) going whining at M$ instead ? b) using appropriate 
configuration.

Your veto is completely invalid anyway.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

Remy, I have to -1 your change in AuthenticatorBase 1.13.  You broke a 
larger case than you fixed -- Mozilla may work now but IE doesn't.  See 
bugs 34083, 27122, 28662, 29336, 29975, and 30618 for the IE problem. 
Mozilla should be fixed in a way compatible with IE.

By uncommenting !isSecure, my change in 1.26 and on can all be backed out.
If no one else is concerned that Tomcat 5.5 doesn't work by default with 
IE under SSL, then I'll withdraw my veto and rename the attribute I 
added to 'securePagesWithPragma' and make the pragma conditional, with a 
default of being included.

Keith
Remy Maucherat wrote:
I see more and more people trying to shove 
down people's throat whatever defaults they like best. 
:-) me too
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
I read:
// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
Indeed (I now remember the issue), there would be serious issues 
should this not be the default.
The issue here is, apparently, that Mozilla has a caching bug we are 
working around, so we have to disable caching.  However, I don't know 
that the broken Mozilla agent requires the Pragma header to do this.
It would be needed to test it. Unfortunately, I didn't mention the bug 
id (assuming there was one), so I don't know exactly what should be tested.

Now, I think you are misrepresenting the IE issue, and it's not such a 
big issue. 
Here is a test war for you and those interested,
.  If you deploy this you will see 
that you cannot download the one file in the webapp with IE with head of 
tree.  If you comment out the pragma header in AuthenticatorBase, it 
works fine.

Despite your renaming, I want to emphasize that I am not talking about 
the cache-control header, and am fine with it being either private or 
no-cache.
The old name was bad. If you want to change it again to something 
better, it's fine.

I am perfectly fine with adding new configurability and documenting it 
properly, but defaults should lean towards the safer solution.
I disagree, defaults should be friendly to the largest client base.
Good, I obviously disagree.
BTW, I really don't see any problem with not using the defaults, and 
actually configuring something. Is that really a big issue for you and 
the people who reported this problem ? For example, in JBoss, I use a 
different default configuration and I don't make a big issue out of it.
I think Tomcat should work with IE under SSL, and yes, I think it is a 
big issue that Tomcat doesn't, out of the box.
I am really annoyed because I see more and more people trying to shove 
down people's throat whatever defaults they like best. This leads to 
improductive discussions. As a result, I'd like to stop here, and move 
on (especially since I don't see the issue as a major problem - the 
mozilla issue, however, was a major problem, as it was potentially 
displaying wrong stuff to users).

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

I read:
// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
Indeed (I now remember the issue), there would be serious issues should 
this not be the default.
The issue here is, apparently, that Mozilla has a caching bug we are 
working around, so we have to disable caching.  However, I don't know 
that the broken Mozilla agent requires the Pragma header to do this.

Now, I think you are misrepresenting the IE issue, and it's not such a 
big issue. 
Here is a test war for you and those interested,
.  If you deploy this you will see 
that you cannot download the one file in the webapp with IE with head of 
tree.  If you comment out the pragma header in AuthenticatorBase, it 
works fine.

Despite your renaming, I want to emphasize that I am not talking about 
the cache-control header, and am fine with it being either private or 
no-cache.

I am perfectly fine with adding new configurability and 
documenting it properly, but defaults should lean towards the safer 
solution.
I disagree, defaults should be friendly to the largest client base.
BTW, I really don't see any problem with not using the defaults, and 
actually configuring something. Is that really a big issue for you and 
the people who reported this problem ? For example, in JBoss, I use a 
different default configuration and I don't make a big issue out of it.
I think Tomcat should work with IE under SSL, and yes, I think it is a 
big issue that Tomcat doesn't, out of the box.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
Pragma has never been sent out on a secure connection until recently 
(rev 1.13)  This is brand new behavior and it causes problems with IE 
under SSL.  At the time you even said you'd be willing to roll it back.
Coincidentally, it was sufficiently long ago that I actually forgot 
about it. I would characterize this as "recently", however, as given the 
version in which it went in, it's in all the stable 5.0.x and 5.5.x builds.

 I'd be happy to leave cache-control to no-cache, it is the Pragma that 
is killing us.  Are you aware of a client that depends solely on Pragma 
for cache instruction?  I would argue that being unable to serve pages 
to IE under SSL is more significant than a caching problem in a client 
that doesn't understand cache-control.
I read:
// FIXME: Disabled for Mozilla FORM support over SSL
// (improper caching issue)
Indeed (I now remember the issue), there would be serious issues should 
this not be the default.

Now, I think you are misrepresenting the IE issue, and it's not such a 
big issue. I am perfectly fine with adding new configurability and 
documenting it properly, but defaults should lean towards the safer 
solution.

BTW, I really don't see any problem with not using the defaults, and 
actually configuring something. Is that really a big issue for you and 
the people who reported this problem ? For example, in JBoss, I use a 
different default configuration and I don't make a big issue out of it.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

Pragma has never been sent out on a secure connection until recently 
(rev 1.13)  This is brand new behavior and it causes problems with IE 
under SSL.  At the time you even said you'd be willing to roll it back. 
 I'd be happy to leave cache-control to no-cache, it is the Pragma that 
is killing us.  Are you aware of a client that depends solely on Pragma 
for cache instruction?  I would argue that being unable to serve pages 
to IE under SSL is more significant than a caching problem in a client 
that doesn't understand cache-control.

Keith
Remy Maucherat wrote:
Keith Wannamaker wrote:
I'd like to omit pragma header by default.  What specific client 
requires it?  The community has identified a specific, widespread 
failure with the former code-- it did not work out of the box with IE 
under SSL.So, if we want to keep the pragma header the default, 
what are the reasons?

I am not willing to discuss this issue. This has been like this forever, 
the behavior was not introduced by myself, and existing flags do exist. 
Your new flag restricts security, and could cause inappropriate caching 
of pages on the client, which could cause user errors on important 
sections of the website.

Rémy
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

Keith Wannamaker wrote:
I'd like to omit pragma header by default.  What specific client 
requires it?  The community has identified a specific, widespread 
failure with the former code-- it did not work out of the box with IE 
under SSL.So, if we want to keep the pragma header the default, what 
are the reasons?
I am not willing to discuss this issue. This has been like this forever, 
the behavior was not introduced by myself, and existing flags do exist. 
Your new flag restricts security, and could cause inappropriate caching 
of pages on the client, which could cause user errors on important 
sections of the website.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Keith Wannamaker]

I'd like to omit pragma header by default.  What specific client 
requires it?  The community has identified a specific, widespread 
failure with the former code-- it did not work out of the box with IE 
under SSL.So, if we want to keep the pragma header the default, what 
are the reasons?

Keith
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:21:57
  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to 
sending
  headers to disable caching.  This is well-intentioned but IE will 
not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.
Per Remy make this behavior optional, with a new valve attribute

When I say "make it optional", I mean: the current behavior should 
remain the default (as it has been since day one, and I am not the one 
who actually did it), but I am ok with having the new proposed behavior 
as an option (and documenting it).

Maybe a better attribute name can be found, BTW. 
IECompatibleProxyCacheDisableHeaders is probably better than 
StupidSettingWhichWillIntroduceBrokenBehaviorIfYouSetItToFalse, but not 
by much.

Rémy
-
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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
keith   2005/04/18 13:21:57
  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  [34083 et al] For webapps with security constraints, we default to sending
  headers to disable caching.  This is well-intentioned but IE will not open
  office documents under SSL with the Pragma header.  Remove the Pragma
  header and change the Cache-Control to private based on comments in
  the many bugs about this and my reading of the 1.1 spec.
  
  Per Remy make this behavior optional, with a new valve attribute
When I say "make it optional", I mean: the current behavior should 
remain the default (as it has been since day one, and I am not the one 
who actually did it), but I am ok with having the new proposed behavior 
as an option (and documenting it).

Maybe a better attribute name can be found, BTW. 
IECompatibleProxyCacheDisableHeaders is probably better than 
StupidSettingWhichWillIntroduceBrokenBehaviorIfYouSetItToFalse, but not 
by much.

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