You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Lyallex <ly...@gmail.com> on 2016/06/23 16:56:07 UTC
I don't understand a recent change released in Tomcat 7.0.70
I'm trying to understand why a recent change in 7.0.70 has been done
the way it has.
The change makes absolutely no sense to me and I need to ask the
implementer why in the name of sanity he did what he did.
I'm talking to you markt whoever you are :-)
Where should I ask the question? dev list?
I couldn't care less how much shouting ensues, I just need to get some sleep.
Thanks
Lyallex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 24 June 2016 at 15:37, Mark Thomas <ma...@apache.org> wrote:
> On 24 June 2016 11:51:25 BST, Lyallex <ly...@gmail.com> wrote:
>
> <snip/>
>
>>However I can't get my head around your assertion that forcing the use
>>of TLS is a 'user data constraint'
>
> Have a look in the Servlet specification for that phrase. I don't have a copy to hand right now but it will be in the security section.
OK. I'll concede that point, thank you for making that clear
In web.xml a security-constraint can contain an
<auth-constraint>
and or a
<user-data-constraint>
It makes sense to me that auth-constraint is associated with a Realm
given that a Realm is a database of users
It still doesn't make sense to me that a user-data-constraint, which
is 'all about the scheme' should be managed/configured/maintained (use
whatever word feels right) in a component that is 'all about a
database'. That's all I'm saying, it just doesn't 'feel right' that's
all.
As for an alternative solution, well until I can get enough time
together to get a build system together I haven't got one, that
doesn't mean that there isn't one. Building Tomcat is now working it's
way up my todo list.
I'll get back to you.
Lyallex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Mark Thomas <ma...@apache.org>.
On 24 June 2016 11:51:25 BST, Lyallex <ly...@gmail.com> wrote:
<snip/>
>However I can't get my head around your assertion that forcing the use
>of TLS is a 'user data constraint'
Have a look in the Servlet specification for that phrase. I don't have a copy to hand right now but it will be in the security section.
> but it appears that any attempted
>discussion of design decisions is considered a criticism at least and
>a personal insult at worst so I won't go there.
Design discussions are fine but your (over) reaction to criticism you imagine you might receive gives your emails an unnecessarily aggressive tone.
There are other places this configuration could go. The Context being the most obvious. However, given the existing relationship between Realm, security constraints and user data constraints, Realm seems more logical. It is also consistent with the general approach in Tomcat of placing configuration on the element that uses it rather having everything on the Context.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 24 June 2016 at 10:01, Mark Thomas <ma...@apache.org> wrote:
> On 24/06/2016 06:30, Lyallex wrote:
>
> <snip/>
>
>> I think the current solution to 59399 need rethinking
>>
>> My commercial site has been up for years, there are links dating back
>> years that refer to the old http scheme
>> I have no control over this, now, whenever I get a hit from an 'old'
>> link I need to force the switch to https, lots of sites have this
>> probem and need a solution, it has nothing whatsoever to do with
>> dabases in any way shape or form.
>>
>> So,
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>>
>> What has the status code returned when switching from http -> https
>> got to do with a Realm?
>
> It is the Realm that enforces the security constraints defined in
> web.xml. This includes both authorisation constraints and user data
> constraints. Forcing the use of TLS is a user data constraint. Hence the
> ability to configure the redirect was added to the Realm implementations.
>
> <snip/>
>
>> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
>> comment seems to imply that all Realms
>> have it (transportGuaranteeRedirectStatus)
>
> It is supported for any Realm that extends org.apache.catalina.RealmBase
> which is all the Realms that ship with Tomcat and, I should think, a
> reasonable proportion of the custom Realm implementations as well.
>
> That it was only documented for one Realm was an oversight that I'll
> correct shortly. (Along with the typo in the text.)
>
> <snip/>
>
>> In the 'good old days' it was common practice to only switch to https
>> during or after signing in to an application, networks were slow and
>> encryption takes time, now networks are faster and the overhead isn't
>> such an issue. Entire sites now use the https scheme, I know mine
>> does. I can see a situation where, because the mighty Google says it
>> must be so, even an entirely static site with no database and no
>> manager will be served up under https. How is such a site suppose to
>> implement https?
>
> I assume the question here is how to configure the redirect status to
> use when a web application does not configure a Realm.
>
> Whether an application configures a Realm or not, it will have one. If a
> web application does not have a specific Realm configured Tomcat looks
> at the Host and then the Engine. If a Realm is not configured for either
> of these then the Engine will be configured with the NullRealm.
>
> Much like the way Tomcat automatically adds an Authenticator when
> required but the user has to add it explicitly if they want to change
> the default configuration for that Authenticator, the user has to
> explicitly add the NullRealm and configure it if they want to change the
> redirect status when no other Realm is defined.
>
> The NullRealm is currently undocumented. I'll fix that as well.
>
>> FYI I have it in black and white, from a Google webaster forum
>> responder that, in the event of a tie between two pages in a ranking
>> calculation, the https scheme would produce a ranking signal that
>> would elevate the https page above the non https page in the resulting
>> rankings.
>>
>> Once again this is not intended as criticsm of a dedicated and
>> prolific committer
>
> You stated you think the current solution needs rethinking. You haven't
> proposed an alternative and explained why the alternative is better.
Because I don't presume to have the knowledge of the Tomcat source
code required to make such a statement.
I do have explicit knowledge of a problem that I experienced while
using open source software that you (and others) have written. I
didn't understand the solution due to (apparently) incomplete
documentation. What *exactly* is one supposed to do in this situation.
I may not have the time to contribute source code but it took me a
while to figure out exactly was going on and write a bug report, I
consider this contributing to the project, maybe you don't.
As it happens I did have a possible solution that maintained your
abstraction (Realm) even though the connection between realm and
redirect is *in my opinion* not intuitive and somewhat opaque and that
was to add the required functionality to the Realm base class (if such
an entity exists). Then, by way of an attribute expose that
functionality in your chosen Realm.
This sounds remarkably like the solution you have come up with ...
However I can't get my head around your assertion that forcing the use
of TLS is a 'user data constraint' but it appears that any attempted
discussion of design decisions is considered a criticism at least and
a personal insult at worst so I won't go there.
Thank you for your explanation and I eagerly await the updated documentation.
Lyallex
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Mark Thomas <ma...@apache.org>.
On 24/06/2016 06:30, Lyallex wrote:
<snip/>
> I think the current solution to 59399 need rethinking
>
> My commercial site has been up for years, there are links dating back
> years that refer to the old http scheme
> I have no control over this, now, whenever I get a hit from an 'old'
> link I need to force the switch to https, lots of sites have this
> probem and need a solution, it has nothing whatsoever to do with
> dabases in any way shape or form.
>
> So,
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>
> What has the status code returned when switching from http -> https
> got to do with a Realm?
It is the Realm that enforces the security constraints defined in
web.xml. This includes both authorisation constraints and user data
constraints. Forcing the use of TLS is a user data constraint. Hence the
ability to configure the redirect was added to the Realm implementations.
<snip/>
> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
> comment seems to imply that all Realms
> have it (transportGuaranteeRedirectStatus)
It is supported for any Realm that extends org.apache.catalina.RealmBase
which is all the Realms that ship with Tomcat and, I should think, a
reasonable proportion of the custom Realm implementations as well.
That it was only documented for one Realm was an oversight that I'll
correct shortly. (Along with the typo in the text.)
<snip/>
> In the 'good old days' it was common practice to only switch to https
> during or after signing in to an application, networks were slow and
> encryption takes time, now networks are faster and the overhead isn't
> such an issue. Entire sites now use the https scheme, I know mine
> does. I can see a situation where, because the mighty Google says it
> must be so, even an entirely static site with no database and no
> manager will be served up under https. How is such a site suppose to
> implement https?
I assume the question here is how to configure the redirect status to
use when a web application does not configure a Realm.
Whether an application configures a Realm or not, it will have one. If a
web application does not have a specific Realm configured Tomcat looks
at the Host and then the Engine. If a Realm is not configured for either
of these then the Engine will be configured with the NullRealm.
Much like the way Tomcat automatically adds an Authenticator when
required but the user has to add it explicitly if they want to change
the default configuration for that Authenticator, the user has to
explicitly add the NullRealm and configure it if they want to change the
redirect status when no other Realm is defined.
The NullRealm is currently undocumented. I'll fix that as well.
> FYI I have it in black and white, from a Google webaster forum
> responder that, in the event of a tie between two pages in a ranking
> calculation, the https scheme would produce a ranking signal that
> would elevate the https page above the non https page in the resulting
> rankings.
>
> Once again this is not intended as criticsm of a dedicated and
> prolific committer
You stated you think the current solution needs rethinking. You haven't
proposed an alternative and explained why the alternative is better.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 25 June 2016 at 07:38, Lyallex <ly...@gmail.com> wrote:
> On 24 June 2016 at 21:50, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Lyallax,
>>
>> Okay, one last time before I start ignoring you. We really are trying
>> to be helpful. But nobody knows why who are so exercised about this.
>>
>> You haven't:
>>
>> a) Clearly explained what you want to do (redirect which requests?
>> with what response code? in what cases?)
>
> Thank you for your very reasonable response
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>
> Explains the problem that has been fixed in 7.0.70
Tomcat 7.0.70, stand alone production server, live.
curl -D /tmp/headers.txt -s http://www.mysite.com/
HTTP/1.1 301 Moved Permanently
...
Fantastic
Thank You
Lyallex
>
> My 'issue' was with the design decision, not the fix.
> Software design is an obsession of mine, sometimes it overflows my
> brain and spills out on the pavement so to speak.
>
> I don't think this forum is the right place to discuss such issues.
> Many thanks for everyones patience.
>
> Lyallex
>
> <snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 24 June 2016 at 21:50, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Lyallax,
>
> Okay, one last time before I start ignoring you. We really are trying
> to be helpful. But nobody knows why who are so exercised about this.
>
> You haven't:
>
> a) Clearly explained what you want to do (redirect which requests?
> with what response code? in what cases?)
Thank you for your very reasonable response
https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
Explains the problem that has been fixed in 7.0.70
My 'issue' was with the design decision, not the fix.
Software design is an obsession of mine, sometimes it overflows my
brain and spills out on the pavement so to speak.
I don't think this forum is the right place to discuss such issues.
Many thanks for everyones patience.
Lyallex
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Lyallax,
Okay, one last time before I start ignoring you. We really are trying
to be helpful. But nobody knows why who are so exercised about this.
You haven't:
a) Clearly explained what you want to do (redirect which requests?
with what response code? in what cases?)
b) Told us what you've tried before (be specific)
c) Explained what in the world your issue has to do with the commit
you have been talking about that first appeared in 7.0.70
...
On 6/24/16 1:19 PM, Lyallex wrote:
> On 24 June 2016 at 16:45, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> <snip>
>
>> 3. You can redirect anything yourself if you want to. The only
>> reason for the Realm option was because Tomcat itself is issuing
>> this particular redirect based upon an authentication situation
>> (as defined by the servlet specification).
>>
>> 4. If you want "easy" redirection from http -> https and you
>> don't want to write the 5-line Filter to do it for you, use
>> url-rewrite and set up a rule that redirects all http:// requests
>> to https:// URLs.
>
> If you really understood the issue you wouldn't make such a lame
> observation it has nothing to do with not being able to redirect,
> it is to do with the *response code* returned by tomcat when the
> redirect occurs.
I understand the relevant issues perfectly. What I don't understand is
why the response code for the Realm is even an issue for you. From
your description, you don't have or need a Realm. You have just
decided that you want to redirect requests using the http:// scheme to
using the https:// scheme, which is perfectly reasonable.
> I have tried a number of things to try and solve this issue using
> Servlet Filters but I just can't seem to get the timing right.
Okay. What did you actually try. Show some code and/or configuration.
> The Tuckey UrlRewriteFilter does not make the slightest bit of
> difference. I know this because I tried it. Did you?
I have user url-rewrite to great effect in various situations.
>> And seriously, calm down.
>
> And seriously, try to understand the issue before criticizing.
>
> You really are a delicate lot aren't you, the slightest suggestion
> that you might not be the geniuses you obviously think you and your
> fragile egos crumple and you get all defensive. I've seen it so
> many times in 20+ years as a developer/software engineer that I
> shouldn't be surprised but I still am.
Nobody is getting defensive, and this isn't about ego. We are trying
to help you and you are just flying off the handle. "THIS CHANGE MAKES
NO SENSE TO ME" and then you talk about how you haven't been able to
make your own code redirect requests. Total non-sequitur IMO.
(In your initial post, you did prepare everyone for a lot of (quite
unnecessary) shouting. I have no idea why shouting would even be
necessary. Did you ever get that sleep you needed?)
I'm happy to help with your root issue... which seems to have nothing
to do with BZ 59399.
>> You completely lost your mind over a new configuration option
>> that you misunderstood.
>
> Oh the irony
http://www.dailymail.co.uk/tvshowbiz/article-3312236/Alanis-Morissette-u
pdates-1995-hit-Ironic-2015-laughs-admits-song-s-lack-ironies.html
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXbZ0lAAoJEBzwKT+lPKRY+10P/3LU/4FK0/IrocXpZCZ5CQgN
7zlps1cT2L1fQz53Vva9BiTfNavwo4gfOuSI4oLJvnmymDuJrdakpj8zKRxwVOyQ
ZUfvTye51o1jS8d4zByGo9xas15G5d2LCrhJlKnMgK1WTebC1K12Q7JqUIJA+tx4
UilOMBZrz1T/M+FtWq7WDdtnZP8oA7yJImBDygncGsjUbDMYduCbMsNBf702ALbM
BY5QB2oqPM8RFAT7oMZXgmM3MMrdqXySk9Wkgf5rFD+PcpAqTQOBJP48FlHzimQK
YKYAT28VPJqD8YfIT4Qe0OpZBCEiYGXd4po36S7BusJFNdg5odv4YParcvgn1ZaB
4ceV1YmmRnTI1V2w7y4rkwAA+0uA0v5WALZZz/stfGPirafyqry2ZrraoWNZ1W+Q
Mm+FNpiCJtQ7i0e5DP2S4zrzT+1lf6W9Bg2ri9hYN5dgVhAcQssQ7NSxieAyM6ib
i1dbA7WOgDvjL4tSB31FHrai1gfq1VuV4gfp3nSDA3UI8sdOne87WJGQfYPwVlUD
k3KnhQQpzGYLY9SYCOW+O0A0Lea1fEUFEM1G4qTu4Jzy3Azg3kTSF4M9z0It2Btt
NeN9OyTOTIZ+uqUs4wt5ZnnE6/c2FjAblKe0hoN0/xNp81PtPplXpIAZoGN6DDI0
JRu3u4W1Jd4iRIzicOv2
=M1A5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 24 June 2016 at 16:45, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
<snip>
> 3. You can redirect anything yourself if you want to. The only reason
> for the Realm option was because Tomcat itself is issuing this
> particular redirect based upon an authentication situation (as defined
> by the servlet specification).
>
> 4. If you want "easy" redirection from http -> https and you don't
> want to write the 5-line Filter to do it for you, use url-rewrite and
> set up a rule that redirects all http:// requests to https:// URLs.
If you really understood the issue you wouldn't make such a lame observation
it has nothing to do with not being able to redirect, it is to do with
the *response code*
returned by tomcat when the redirect occurs.
I have tried a number of things to try and solve this issue using
Servlet Filters but I just can't seem to get the timing right.
The Tuckey UrlRewriteFilter does not make the slightest bit of difference.
I know this because I tried it. Did you?
> And seriously, calm down.
And seriously, try to understand the issue before criticizing.
You really are a delicate lot aren't you, the slightest suggestion
that you might not be the geniuses you obviously think you
and your fragile egos crumple and you get all defensive. I've seen it
so many times in 20+ years as a developer/software engineer that I
shouldn't be surprised but I still am.
.
> You completely lost your mind over a new
> configuration option that you misunderstood.
Oh the irony
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Lyllax,
On 6/24/16 1:30 AM, Lyallex wrote:
> On 23 June 2016 at 19:43, Mark Thomas <ma...@apache.org> wrote:
>> On 23/06/2016 17:56, Lyallex wrote:
>>> I'm trying to understand why a recent change in 7.0.70 has been
>>> done the way it has. The change makes absolutely no sense to me
>>> and I need to ask the implementer why in the name of sanity he
>>> did what he did. I'm talking to you markt whoever you are :-)
>>>
>>> Where should I ask the question? dev list?
>>>
>>> I couldn't care less how much shouting ensues, I just need to
>>> get some sleep.
>>
>> How about you cut the attitude and just ask your question?
>
> OK, I will.
>
> To give this some context and with the greatest respect to a
> dedicated committer none of what follows is intended as criticism
> it's just that I think the current solution to 59399 need
> rethinking
>
> My commercial site has been up for years, there are links dating
> back years that refer to the old http scheme I have no control over
> this, now, whenever I get a hit from an 'old' link I need to force
> the switch to https, lots of sites have this probem and need a
> solution, it has nothing whatsoever to do with dabases in any way
> shape or form.
>
> So,
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>
> What has the status code returned when switching from http ->
> https got to do with a Realm?
>
> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
>
> <cite> "A Realm is a "database" of usernames and passwords that
> identify valid users of a web application .. " </cite>
>
> Or: What has the status code returned when switching from http ->
> https got to do with a database of usernames and passwords?
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/realm.html
>
> JDBCDatabaseRealm
>
> attrbute: transportGuaranteeRedirectStatus
>
> <cite> The HTTP status code to use when the container needs to
> issue an HTTP redirect to meet the requirements of a configured
> transport guarantee. The prpvoded status code is not validated. If
> not specified, the default value of 302 is used. </cite>
>
> I just don't get why this is here
>
> furthermore https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>
> <cite> Mark Thomas 2016-06-15 11:12:11 UTC
>
> This has been implemented as a new option in the Realm and will
> has implemented in: - 9.0.x for 9.0.0.M9 onwards - 8.5.x for 8.5.4
> onwards - 8.0.x for 8.0.37 onwards - 7.0.x for 7.0.70 onwards
> </cite>
>
> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
> comment seems to imply that all Realms have it
> (transportGuaranteeRedirectStatus)
>
> In which case surely it should be a common attribute and (I'm
> guessing here) the functionality be included in the base class for
> Realm
>
> What happens if I don't use JDBCDatabaseRealm, does that mean I
> can't configure the switchover status code. What happens if I write
> my own Realm?
>
> In the 'good old days' it was common practice to only switch to
> https during or after signing in to an application, networks were
> slow and encryption takes time, now networks are faster and the
> overhead isn't such an issue. Entire sites now use the https
> scheme, I know mine does. I can see a situation where, because the
> mighty Google says it must be so, even an entirely static site with
> no database and no manager will be served up under https. How is
> such a site suppose to implement https?
>
> FYI I have it in black and white, from a Google webaster forum
> responder that, in the event of a tie between two pages in a
> ranking calculation, the https scheme would produce a ranking
> signal that would elevate the https page above the non https page
> in the resulting rankings.
>
> Once again this is not intended as criticsm of a dedicated and
> prolific committer
Wow, what a diatribe. What is necessary?
1. This is a new option which defaults to the previous behavior. This
should literally effect nobody except people who care about it.
2. There is a bug in the documentation which suggests that its only
available for a single Realm when it is in fact available for all Realms
.
3. You can redirect anything yourself if you want to. The only reason
for the Realm option was because Tomcat itself is issuing this
particular redirect based upon an authentication situation (as defined
by the servlet specification).
4. If you want "easy" redirection from http -> https and you don't
want to write the 5-line Filter to do it for you, use url-rewrite and
set up a rule that redirects all http:// requests to https:// URLs.
And seriously, calm down. You completely lost your mind over a new
configuration option that you misunderstood. You made it sound like we
introduced a breaking change to a product that brought-down your whole
enterprise. But the reality is that a relatively benign commit has
completely enraged you for ... what reason exactly?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXbVWPAAoJEBzwKT+lPKRYafkQAK5XR8ePljpPb88jwsfPZoGp
+USL/hgqPI9FZOQ2XS96P7kc8oihjYCEYL38jqoXkXDC1Y263ulgEXqvKCwFN1cq
oDXEtCXH+WvaaFF+N0jR6t2qbZEZ5dd36gCnuI7oXdT49kUbySeJ+xOnx6b/uBg0
2KAkxSzIA/EzsC/C3Z+Aj+HibZY6bklNFliU93EBFLdO0MrXKxvCYe1lfTwYn5v9
OFH/dCqzmlFt6byDW0IQTHi1n0tvwVLJrORTEBwGAAEjWfvQ/MgPPs3OZj9WVKa9
dxsZ2jURaEJt88S7iahIIePRijDpZ4TrRKAuqCbtnOLphwki83i2S+yoMCHf2BML
b0naBnrCDzDnZ8J6uQrE+u79RM+r54o5MO+cgsiXGccTm4gDT/SsiEFaGn4hH6BO
sUvM4yEFrme2TQYfnvum0S5FiyD10SxxO/ip0wtdvi8605aKXD5vV1ND1e+WGz3h
jn4pB4W7lbXmM7WA9SjVwP4vIT7jBEHrIWWtTijVhNjB/TcCEk3K1Xd1dFd1LjF2
/UNBYqUhlk3gAloHUhaBOapL59IqpPgaMWANFnPZVAmWDaPQauHFbAaEPkmbdzxB
UrxyttgxwghECxcoUPiQbK6qClHNpdndGNUhq4FKFv7d2Lk95LGGBlm0sSW+Gl43
vQ2usLFeI7CA2ROsjLAS
=zxsY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Lyallex <ly...@gmail.com>.
On 23 June 2016 at 19:43, Mark Thomas <ma...@apache.org> wrote:
> On 23/06/2016 17:56, Lyallex wrote:
>> I'm trying to understand why a recent change in 7.0.70 has been done
>> the way it has.
>> The change makes absolutely no sense to me and I need to ask the
>> implementer why in the name of sanity he did what he did.
>> I'm talking to you markt whoever you are :-)
>>
>> Where should I ask the question? dev list?
>>
>> I couldn't care less how much shouting ensues, I just need to get some sleep.
>
> How about you cut the attitude and just ask your question?
OK, I will.
To give this some context and with the greatest respect to a dedicated
committer none of what follows is intended as criticism it's just that
I think the current solution to 59399 need rethinking
My commercial site has been up for years, there are links dating back
years that refer to the old http scheme
I have no control over this, now, whenever I get a hit from an 'old'
link I need to force the switch to https, lots of sites have this
probem and need a solution, it has nothing whatsoever to do with
dabases in any way shape or form.
So,
https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
What has the status code returned when switching from http -> https
got to do with a Realm?
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
<cite>
"A Realm is a "database" of usernames and passwords that identify
valid users of a web application .. "
</cite>
Or: What has the status code returned when switching from http ->
https got to do with a database of usernames and passwords?
https://tomcat.apache.org/tomcat-7.0-doc/config/realm.html
JDBCDatabaseRealm
attrbute: transportGuaranteeRedirectStatus
<cite>
The HTTP status code to use when the container needs to issue an HTTP
redirect to meet the requirements of a configured transport guarantee.
The prpvoded status code is not validated. If not specified, the
default value of 302 is used.
</cite>
I just don't get why this is here
furthermore
https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
<cite>
Mark Thomas 2016-06-15 11:12:11 UTC
This has been implemented as a new option in the Realm and will has
implemented in:
- 9.0.x for 9.0.0.M9 onwards
- 8.5.x for 8.5.4 onwards
- 8.0.x for 8.0.37 onwards
- 7.0.x for 7.0.70 onwards
</cite>
Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
comment seems to imply that all Realms
have it (transportGuaranteeRedirectStatus)
In which case surely it should be a common attribute and (I'm guessing
here) the functionality be included in the base class for Realm
What happens if I don't use JDBCDatabaseRealm, does that mean I can't
configure the switchover status code.
What happens if I write my own Realm?
In the 'good old days' it was common practice to only switch to https
during or after signing in to an application, networks were slow and
encryption takes time, now networks are faster and the overhead isn't
such an issue. Entire sites now use the https scheme, I know mine
does. I can see a situation where, because the mighty Google says it
must be so, even an entirely static site with no database and no
manager will be served up under https. How is such a site suppose to
implement https?
FYI I have it in black and white, from a Google webaster forum
responder that, in the event of a tie between two pages in a ranking
calculation, the https scheme would produce a ranking signal that
would elevate the https page above the non https page in the resulting
rankings.
Once again this is not intended as criticsm of a dedicated and
prolific committer
With respect
Lyallex
>
> If you are ever unsure where to ask, use the users list.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: I don't understand a recent change released in Tomcat 7.0.70
Posted by Mark Thomas <ma...@apache.org>.
On 23/06/2016 17:56, Lyallex wrote:
> I'm trying to understand why a recent change in 7.0.70 has been done
> the way it has.
> The change makes absolutely no sense to me and I need to ask the
> implementer why in the name of sanity he did what he did.
> I'm talking to you markt whoever you are :-)
>
> Where should I ask the question? dev list?
>
> I couldn't care less how much shouting ensues, I just need to get some sleep.
How about you cut the attitude and just ask your question?
If you are ever unsure where to ask, use the users list.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org