Remaining Tomcat 10 items

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Remaining Tomcat 10 items

remm
Hi,

I'm looking at the TODO list, in addition to some extra items. In order ...

- Java 11.
I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be] required for Tomcat 10 ? It could be better to do it in 10.1.

- Remove the use of system properties to control configuration wherever possible.
I still don't see the point for quite a few of them. For others however, using sys props was a mistake, example the facade recycling. Also, the digester can now pull from system and env properties, giving full flexibility. Also also, this is a handy way to do things in cloud. I think we should target the ones which should make sense.

- Reduce instances of setters and getters for the same property existing on an object and its parent. This may require new objects to be exposed via JMX.
Fixed enough ?

- Remove APR connector.
Is there still general approval for that, and is that still the plan for Tomcat 10.0 ?

- Clean-up content-type header processing.
No opinion on that.

- RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT equivalent to the decoded form. Provide an option not to decode delimiters in %nn form.
Mark is working on it.

- Refactor DefaultServlet to use Ranges in parseRanges().
I looked at it and I don't get it.
The parser here requires a '=' but that should be a space in content-range (ranges uses the '=' however), the example given in the spec is "Content-Range: bytes 42-1233/1234".
Just wondering before starting to refactor.

Rémy

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

markt
On 23/03/2020 09:37, Rémy Maucherat wrote:
> Hi,
>
> I'm looking at the TODO list, in addition to some extra items. In order ...
>
> - Java 11.
> I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be]
> required for Tomcat 10 ? It could be better to do it in 10.1.

No. It will be Java 8.

> - Remove the use of system properties to control configuration wherever
> possible.
> I still don't see the point for quite a few of them. For others however,
> using sys props was a mistake, example the facade recycling. Also, the
> digester can now pull from system and env properties, giving full
> flexibility. Also also, this is a handy way to do things in cloud. I
> think we should target the ones which should make sense.

For "wherever possible" read "where it makes sense to do so". My
intention was to target those system properties that were targetted at a
specific component and could/should be configured there.

> - Reduce instances of setters and getters for the same property existing
> on an object and its parent. This may require new objects to be exposed
> via JMX.
> Fixed enough ?

From memory, this was primarily on the Connectors. That is certainly a
lot better. I'd like to review things before closing this one out.

> - Remove APR connector.
> Is there still general approval for that, and is that still the plan for
> Tomcat 10.0 ?

It feels like a big step but I do think this is the right thing to do.

> - Clean-up content-type header processing.
> No opinion on that.

It fixes an edge case bug. I have a plan for this. As long as it is done
before things go stable there is no rush.

> - RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT
> equivalent to the decoded form. Provide an option not to decode
> delimiters in %nn form.
> Mark is working on it.

I'm close to a patch for this but I got distracted with HTTP/0.9 issues.

> - Refactor DefaultServlet to use Ranges in parseRanges().
> I looked at it and I don't get it.
> In particular the Content-Ranges header
> (https://tools.ietf.org/html/rfc7233#section-4.2) that uses
> https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/ContentRange.java#L75
> The parser here requires a '=' but that should be a space in
> content-range (ranges uses the '=' however), the example given in the
> spec is "Content-Range: bytes 42-1233/1234".
> Just wondering before starting to refactor.

That is the response header, not the request header. Take a look at
sections 2.1 and 3.1

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

Christopher Schultz-2
In reply to this post by remm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 3/23/20 05:37, Rémy Maucherat wrote:
> I'm looking at the TODO list, in addition to some extra items. In
> order ...
>
> - Remove APR connector. Is there still general approval for that,
> and is that still the plan for Tomcat 10.0 ?

See the thread "[PROPOSAL] Tomcat 10: Drop AJP Connector" from
2019-10-07 and later. All replies were in favor of dropping AJP
support, though there were not a large number of those replies.
(michael-o had a concern about some performance problem in the HTTP
connector(s) but it seems that was a regression that was corrected
immediately after it was reported.)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl54ytUACgkQHPApP6U8
pFj81A//QoeYRkzDCw/acYy1FOlrWGapDnvP/Am4sr4UDtcMjjLpGP7SyhMv2EOE
k5ndZ7xO+WFpzGVa13a5kzfrHGUt2m3mbZDMpkLsW2x55FUfq+Oe3g4e8g0Bjsmw
5zVwoOWuap+6wRN3dqNAQ3ZAPDBSz62xocY+daqNtmnKijmqyAMIxL4bqzRHaVQW
dpJeWRCQ2W4eg66594HSr59qfJ1XyiXH8jLYxEHvDA1+ilCOZC+hCBLvGO24KUx3
yJhc6ZbnQKhvb9W9tG1x8jls3H571ySno5dQ7YSFultv+dTtSNPL6dmS0stTCeNH
KvlJbwEip/ic1at3osr6Ua4Zq/IWSuedt7mRoXWx2M8SEldGTOY1HoM7ZB1jzcK+
25A46rq7knctJ1zDw5UXwL3s91qP7y1pwjCdX6UCfiu0XQg80VUXDKv1HiGH1aj1
lGxzG/INEios8SBHUpKKuXvDfd8Sm/z54VQSlvmBr817eX3ljdb1XR6o/Ld1KmiC
1eutQyZ2vIWBD3sR8BEum+9FvQ/XpINArSirC/DQVHP0TfInQlQq60dry4OjPFX2
delqCOM6pyVur9I362HKwgPXHHAGwdx8mWpC536nsNw3m0YMdW3dVImjbtz9nZ3H
GSeGziYslnKHAh8WmH5UxHJL59BXFTCTMUOOvIqsZkWDH3UuWmk=
=31Oo
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

Michael Osipov
Am 2020-03-23 um 15:42 schrieb Christopher Schultz:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Rémy,
>
> On 3/23/20 05:37, Rémy Maucherat wrote:
>> I'm looking at the TODO list, in addition to some extra items. In
>> order ...
>>
>> - Remove APR connector. Is there still general approval for that,
>> and is that still the plan for Tomcat 10.0 ?
>
> See the thread "[PROPOSAL] Tomcat 10: Drop AJP Connector" from
> 2019-10-07 and later. All replies were in favor of dropping AJP
> support, though there were not a large number of those replies.
> (michael-o had a concern about some performance problem in the HTTP
> connector(s) but it seems that was a regression that was corrected
> immediately after it was reported.)

It was a misconfiguration of the tests on master. With Mark's test code
I was able to find the minimal required buffer size for three operating
systems.

I will run master tests on several OSes and OpenJDK versions again and
compare numbers. If they are significantly different, I will report them.

M


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

Michael Osipov
In reply to this post by remm
Am 2020-03-23 um 10:37 schrieb Rémy Maucherat:
> Hi,
>
> I'm looking at the TODO list, in addition to some extra items. In order ...

You missed one point:

Remove deprecated code marked for removal in Tomcat 10.

M


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

remm
In reply to this post by markt
On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas <[hidden email]> wrote:
On 23/03/2020 09:37, Rémy Maucherat wrote:
> Hi,
>
> I'm looking at the TODO list, in addition to some extra items. In order ...
>
> - Java 11.
> I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be]
> required for Tomcat 10 ? It could be better to do it in 10.1.

No. It will be Java 8.

> - Remove the use of system properties to control configuration wherever
> possible.
> I still don't see the point for quite a few of them. For others however,
> using sys props was a mistake, example the facade recycling. Also, the
> digester can now pull from system and env properties, giving full
> flexibility. Also also, this is a handy way to do things in cloud. I
> think we should target the ones which should make sense.

For "wherever possible" read "where it makes sense to do so". My
intention was to target those system properties that were targetted at a
specific component and could/should be configured there.

> - Reduce instances of setters and getters for the same property existing
> on an object and its parent. This may require new objects to be exposed
> via JMX.
> Fixed enough ?

From memory, this was primarily on the Connectors. That is certainly a
lot better. I'd like to review things before closing this one out.

> - Remove APR connector.
> Is there still general approval for that, and is that still the plan for
> Tomcat 10.0 ?

It feels like a big step but I do think this is the right thing to do.

> - Clean-up content-type header processing.
> No opinion on that.

It fixes an edge case bug. I have a plan for this. As long as it is done
before things go stable there is no rush.

> - RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT
> equivalent to the decoded form. Provide an option not to decode
> delimiters in %nn form.
> Mark is working on it.

I'm close to a patch for this but I got distracted with HTTP/0.9 issues.

> - Refactor DefaultServlet to use Ranges in parseRanges().
> I looked at it and I don't get it.
> In particular the Content-Ranges header
> (https://tools.ietf.org/html/rfc7233#section-4.2) that uses
> https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/ContentRange.java#L75
> The parser here requires a '=' but that should be a space in
> content-range (ranges uses the '=' however), the example given in the
> spec is "Content-Range: bytes 42-1233/1234".
> Just wondering before starting to refactor.

That is the response header, not the request header. Take a look at
sections 2.1 and 3.1

Right, I had forgotten that. Fun stuff.
I hope I didn't break anything with that refactoring ...

Rémy
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

remm
In reply to this post by markt
On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas <[hidden email]> wrote:
> - Reduce instances of setters and getters for the same property existing
> on an object and its parent. This may require new objects to be exposed
> via JMX.
> Fixed enough ?

From memory, this was primarily on the Connectors. That is certainly a
lot better. I'd like to review things before closing this one out.

There's indeed a problem on Connector, but I don't see how to fix it.

Ex:
    public void setMaxPostSize(int maxPostSize) {
        this.maxPostSize = maxPostSize;
        setProperty("maxPostSize", String.valueOf(maxPostSize));
    }

Both Catalina and Coyote need to access the value. The alternative would be to have the Catalina code use getProperty, which would be both uglier and slower.

Rémy

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

remm
In reply to this post by remm
On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat <[hidden email]> wrote:
- Remove the use of system properties to control configuration wherever possible.
I still don't see the point for quite a few of them. For others however, using sys props was a mistake, example the facade recycling. Also, the digester can now pull from system and env properties, giving full flexibility. Also also, this is a handy way to do things in cloud. I think we should target the ones which should make sense.

I think I'm done with that area for now as I'm a bit skeptical about this for JULI, EL, JSP and Websockets. Any reasonable candidates for removal left ?

Rémy
Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

markt
In reply to this post by remm
On 25/03/2020 13:43, Rémy Maucherat wrote:

> On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > - Reduce instances of setters and getters for the same property
>     existing
>     > on an object and its parent. This may require new objects to be
>     exposed
>     > via JMX.
>     > Fixed enough ?
>
>     From memory, this was primarily on the Connectors. That is certainly a
>     lot better. I'd like to review things before closing this one out.
>
>
> There's indeed a problem on Connector, but I don't see how to fix it.
>
> Ex:
>     public void setMaxPostSize(int maxPostSize) {
>         this.maxPostSize = maxPostSize;
>         setProperty("maxPostSize", String.valueOf(maxPostSize));
>     }
>
> Both Catalina and Coyote need to access the value. The alternative would
> be to have the Catalina code use getProperty, which would be both uglier
> and slower.

I don't see any use of that particular property in Coyote. I think the
setProperty() call can be removed.

I'm not so sure I'll be able to do that for all the similar calls but
I'll take a look.

Context was another area where there has been a lot of this. I'll look
there too.

What I probably need to is start making a note of them when I see them
and deal with them at the next refactoring opportunity.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

remm
On Fri, Mar 27, 2020 at 4:54 PM Mark Thomas <[hidden email]> wrote:
On 25/03/2020 13:43, Rémy Maucherat wrote:
> On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > - Reduce instances of setters and getters for the same property
>     existing
>     > on an object and its parent. This may require new objects to be
>     exposed
>     > via JMX.
>     > Fixed enough ?
>
>     From memory, this was primarily on the Connectors. That is certainly a
>     lot better. I'd like to review things before closing this one out.
>
>
> There's indeed a problem on Connector, but I don't see how to fix it.
>
> Ex:
>     public void setMaxPostSize(int maxPostSize) {
>         this.maxPostSize = maxPostSize;
>         setProperty("maxPostSize", String.valueOf(maxPostSize));
>     }
>
> Both Catalina and Coyote need to access the value. The alternative would
> be to have the Catalina code use getProperty, which would be both uglier
> and slower.

I don't see any use of that particular property in Coyote. I think the
setProperty() call can be removed.

:D
Grep confirms that we can remove the setProperty. Ok, that was a horrible example, but a few others in Connector are useful in both (like maxSavePostSize, which is one I looked at, then I wrote the post talking about maxPostSize).
 

I'm not so sure I'll be able to do that for all the similar calls but
I'll take a look.

Context was another area where there has been a lot of this. I'll look
there too.

What I probably need to is start making a note of them when I see them
and deal with them at the next refactoring opportunity.

Ok.

Rémy

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

markt
On 27/03/2020 16:13, Rémy Maucherat wrote:

> On Fri, Mar 27, 2020 at 4:54 PM Mark Thomas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 25/03/2020 13:43, Rémy Maucherat wrote:
>     > On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     > - Reduce instances of setters and getters for the same property
>     >     existing
>     >     > on an object and its parent. This may require new objects to be
>     >     exposed
>     >     > via JMX.
>     >     > Fixed enough ?
>     >
>     >     From memory, this was primarily on the Connectors. That is
>     certainly a
>     >     lot better. I'd like to review things before closing this one out.
>     >
>     >
>     > There's indeed a problem on Connector, but I don't see how to fix it.
>     >
>     > Ex:
>     >     public void setMaxPostSize(int maxPostSize) {
>     >         this.maxPostSize = maxPostSize;
>     >         setProperty("maxPostSize", String.valueOf(maxPostSize));
>     >     }
>     >
>     > Both Catalina and Coyote need to access the value. The alternative
>     would
>     > be to have the Catalina code use getProperty, which would be both
>     uglier
>     > and slower.
>
>     I don't see any use of that particular property in Coyote. I think the
>     setProperty() call can be removed.
>
>
> :D
> Grep confirms that we can remove the setProperty. Ok, that was a
> horrible example, but a few others in Connector are useful in both (like
> maxSavePostSize, which is one I looked at, then I wrote the post talking
> about maxPostSize).

The ones we need to keep are (I think):

asyncTimeout
maxSavePostSize
port
portOffset
localPort
secure

In terms of simplification, we could leave them as is or:
- Add them to ProtocolHandler
- Refactor Connector to pass the getter/setter calls to the
  ProtocolHandler instance.

I'm currently running a set of unit tests with the other setProperty()
calls removed to confirm I haven't missed anything.

I haven't looked elsewhere yet.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

markt
In reply to this post by remm
On 26/03/2020 16:47, Rémy Maucherat wrote:

> On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     - Remove the use of system properties to control configuration
>     wherever possible.
>     I still don't see the point for quite a few of them. For others
>     however, using sys props was a mistake, example the facade
>     recycling. Also, the digester can now pull from system and env
>     properties, giving full flexibility. Also also, this is a handy way
>     to do things in cloud. I think we should target the ones which
>     should make sense.
>
>
> I think I'm done with that area for now as I'm a bit skeptical about
> this for JULI, EL, JSP and Websockets. Any reasonable candidates for
> removal left ?

Digester
 - Not sure. Likely to be tricky

Clustering
 - org.apache.catalina.tribes.dns_lookups
   Any DNS names are going to *have* to be resolved at some point for
   the cluster to work. I'd probably remove this and let the user
   specify DNS name or IP address as they wish.

EL
 - Can't do anything about these without spec changes

Jasper
 - Could all move to o.a.jasper.Options

Security
 - ALLOW_BACKSLASH
   Remove it. It is just wrong. If we must keep it, move it to the
   Connector.
 - ALLOW_ENCODED_SLASH
   I plan to replace this with a Connector option

Spec
 - STRICT_SERVLET_COMPLIANCE
   Is a useful short-cut
 - Move the remaining ones to the Context or related object where
   possible (I haven't checked how easy that would be)

Sessions
 - Move to the Manager or related object where possible (I haven't
   checked how easy that would be)

JULI
 - Look tricky to remove any of these.

JAR Scanning
 - Leave as is

WebSockets
 - Ideally want to set these per web app but we'd need to find a
   configuration mechanism to use

Other
 - Looks like NioSelectorShared has already been refactored out.
 - The rest look difficult to remove.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

remm
On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas <[hidden email]> wrote:
On 26/03/2020 16:47, Rémy Maucherat wrote:
> On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     - Remove the use of system properties to control configuration
>     wherever possible.
>     I still don't see the point for quite a few of them. For others
>     however, using sys props was a mistake, example the facade
>     recycling. Also, the digester can now pull from system and env
>     properties, giving full flexibility. Also also, this is a handy way
>     to do things in cloud. I think we should target the ones which
>     should make sense.
>
>
> I think I'm done with that area for now as I'm a bit skeptical about
> this for JULI, EL, JSP and Websockets. Any reasonable candidates for
> removal left ?

Digester
 - Not sure. Likely to be tricky

That sounds impossible since it happens before parsing of server.xml, so no real way to configure besides system properties.
 

Clustering
 - org.apache.catalina.tribes.dns_lookups
   Any DNS names are going to *have* to be resolved at some point for
   the cluster to work. I'd probably remove this and let the user
   specify DNS name or IP address as they wish.

Ok. I think it's totally useless so I chose not to care about it ;)
 

EL
 - Can't do anything about these without spec changes

Jasper
 - Could all move to o.a.jasper.Options

Possibly yes. Quite a bit of work there.

Security
 - ALLOW_BACKSLASH
   Remove it. It is just wrong. If we must keep it, move it to the
   Connector.
 - ALLOW_ENCODED_SLASH
   I plan to replace this with a Connector option

I moved both to the Connector already, they can be removed as needed.
 

Spec
 - STRICT_SERVLET_COMPLIANCE
   Is a useful short-cut

+1
 
 - Move the remaining ones to the Context or related object where
   possible (I haven't checked how easy that would be)

I moved them to Context.
 

Sessions
 - Move to the Manager or related object where possible (I haven't
   checked how easy that would be)

I moved them to Manager.

JULI
 - Look tricky to remove any of these.

JAR Scanning
 - Leave as is

WebSockets
 - Ideally want to set these per web app but we'd need to find a
   configuration mechanism to use

Other
 - Looks like NioSelectorShared has already been refactored out.

Yes, I removed that one from the doc.
 
 - The rest look difficult to remove.

Rémy
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

Christopher Schultz-2
In reply to this post by markt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 3/27/20 13:12, Mark Thomas wrote:
> Spec - STRICT_SERVLET_COMPLIANCE Is a useful short-cut - Move the
> remaining ones to the Context or related object where possible (I
> haven't checked how easy that would be)

Would it be possible to have this available as a <Context> option? It
would basically just change all the default options for that one
<Context>. How much spec-compliance behavior is maintained at levels
higher than <Context>? I agree it IS a useful short-cut. But having it
as a system property is quite ugly.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CSDIACgkQHPApP6U8
pFiy3hAAgzJrDBBQvH3yLkKRMheDKsfQLqTfz0v38g2IMdD3p40NolL3NFjrRx+Q
SZtuzPPozo6vBgcncnjuxwe7mYPLQWm56j/fbcftppIIhfGVgA0pbD3u2iFDu1TE
zAYQBw0ZomCmB+YN/5OCM1li4Y9/aVMKfSm0SoT8jh1boSQ1TT/mWkMx8cATnMr0
nhSV4ALwB/5jkPSl78rCsSBqnBPNJig1zaNNwbkS6uW4bQcDHvGEIx0mfT/bcM0t
QTkClBy0zE+LeanigPPz0bKrA0Yo6VqhNA88hZYX1x7dNaY1872Mv9TLJZ7/g/z/
fxxM/KU+MUsW7l0XsaPvWYjmkqPRTpdyKhcroEAHmv/ZEcPGvomxLLLoculoYOmY
IARFR7w+XXJ4f0FGNV0/OZmCLqJZG/wZyweKOyTjfnPV7HtzNJNPnnJa8k19934H
bIwlziyk/Y5fUAoz8pPtMvsl5+lRSSTgqOZnQITioMdEhAve1SG8kaKDrQ29cKGk
dFFgcfcC8Z9+74yQ5nCnP9JOprI/N9A695zQzo4mcu3VgxaigrqoU23m+yZRCCY5
GZr6OOCIH96/XjAivdbtwa79ga01FDPxsiF4RQD2W+f2tR1Otkn7FQ6vaDjLok4s
4ZmGiISBwrNFiULmHnOZqdvqCeWgkxkUtYoJguDSUykz3/b0M9E=
=ULKX
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Remaining Tomcat 10 items

markt
On 30/03/2020 20:27, Christopher Schultz wrote:

> Mark,
>
> On 3/27/20 13:12, Mark Thomas wrote:
>> Spec - STRICT_SERVLET_COMPLIANCE Is a useful short-cut - Move the
>> remaining ones to the Context or related object where possible (I
>> haven't checked how easy that would be)
>
> Would it be possible to have this available as a <Context> option? It
> would basically just change all the default options for that one
> <Context>. How much spec-compliance behavior is maintained at levels
> higher than <Context>?

At a quick glance, only the URIEncoding on the Connector.

Hang on. Servlet 4 (12.1) changed the default to UTF-8. We need to clean
up the code / docs in light of that. Once that is done it looks like
this might be moveable to the Context.

Mark


> I agree it IS a useful short-cut. But having it
> as a system property is quite ugly.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]