Re: Delay between release tags and announcement
On 21/07/2022 07:06, Nemo wrote: What happens if a vote doesn't pass or get vetoed - do the tags get deleted? Release votes cannot be vetoed. If a release vote doesn't pass, that release doesn't happen. In Tomcat, we'll fix whatever the problem was and then do another release. Version numbers are cheap so we just use the next one. Once any artefacts have been made public using that tag - including for a release vote we never delete the tag as it is part of the record of what was voted on. If we spot an issue with a tag before anything is uploaded, we will delete the tag, fix the issue and re-tag. Perhaps the tagging/voting process should include a rc tag instead of a release tag, so as to avoid getting released downstream accidentally? I don't see that happening. We have to vote on exactly what is being released. So even if we vote on an a.b.c-RC1 its version number has to be a.b.c. That creates an issue if we have multiple RCs. When a user reports an issue with version a.b.c we can't tell if that is a.b.c-RC1, a.b.c-RC2, a.b.c-RC3 etc. There are ways to address this with the version number (e.g. add a build number) but we have been doing it this way for quite a while and it works for us. Generally, I'd strongly discourage anyone from assuming that GitHub tag == ASF release. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Fix typo
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/main by this push: new c8fce99bd7 Fix typo c8fce99bd7 is described below commit c8fce99bd7a688603c2e68a559124881ec01a066 Author: Mark Thomas AuthorDate: Thu Jul 21 09:12:22 2022 +0100 Fix typo --- webapps/docs/changelog.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index adf784ccb6..403b3ef4e7 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -135,8 +135,8 @@ (markt) -Remove the jmvRoute system property used to configure a -default value for the jmvRoute attribute of an Engine. +Remove the jvmRoute system property used to configure a +default value for the jvmRoute attribute of an Engine. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.0.x updated: Fix typo
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 10.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/10.0.x by this push: new 3e828acf88 Fix typo 3e828acf88 is described below commit 3e828acf88bc195a301db4226eeae7ec549edcc3 Author: Mark Thomas AuthorDate: Thu Jul 21 09:14:38 2022 +0100 Fix typo --- webapps/docs/changelog.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 722abd538f..f604e498c2 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -128,8 +128,8 @@ (markt) -Deprecated the jmvRoute system property used to configure a -default value for the jmvRoute attribute of an Engine. +Deprecated the jvmRoute system property used to configure a +default value for the jvmRoute attribute of an Engine. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Fix typo
This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new b5ec61e01e Fix typo b5ec61e01e is described below commit b5ec61e01eb4a583e1c8619ebeaa1cff47add530 Author: Mark Thomas AuthorDate: Thu Jul 21 09:14:38 2022 +0100 Fix typo --- webapps/docs/changelog.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml index 8da9d71bb5..67edae49fc 100644 --- a/webapps/docs/changelog.xml +++ b/webapps/docs/changelog.xml @@ -130,8 +130,8 @@ (markt) -Deprecated the jmvRoute system property used to configure a -default value for the jmvRoute attribute of an Engine. +Deprecated the jvmRoute system property used to configure a +default value for the jvmRoute attribute of an Engine. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 8.5.82
All, I was on holiday last week and will be out again today through Monday. Looking at the changelog for 8.5.x, I don't see anything pressing[1], so I'm thinking of just waiting for August to kind of reset the clock on releases back to the beginning(ish) of each month. Please let me know in the next 3-4 hours if anyone disagrees and I'll roll the release and put it out for a vote before I leave. Thanks, -chris [1] The only "important" thing is an upgrade of bundled OpenSSL for Windows users, but they can grab an updated tcnative release if necessary. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Delay between release tags and announcement
Nemo, Mark, On 7/21/22 04:06, Mark Thomas wrote: On 21/07/2022 07:06, Nemo wrote: What happens if a vote doesn't pass or get vetoed - do the tags get deleted? Release votes cannot be vetoed. If a release vote doesn't pass, that release doesn't happen. In Tomcat, we'll fix whatever the problem was and then do another release. Version numbers are cheap so we just use the next one. Once any artefacts have been made public using that tag - including for a release vote we never delete the tag as it is part of the record of what was voted on. If we spot an issue with a tag before anything is uploaded, we will delete the tag, fix the issue and re-tag. Perhaps the tagging/voting process should include a rc tag instead of a release tag, so as to avoid getting released downstream accidentally? I don't see that happening. We have to vote on exactly what is being released. So even if we vote on an a.b.c-RC1 its version number has to be a.b.c. That creates an issue if we have multiple RCs. When a user reports an issue with version a.b.c we can't tell if that is a.b.c-RC1, a.b.c-RC2, a.b.c-RC3 etc. There are ways to address this with the version number (e.g. add a build number) but we have been doing it this way for quite a while and it works for us. Generally, I'd strongly discourage anyone from assuming that GitHub tag == ASF release. I generally agree with Mark, here, with one caveat: It would be very easy for our release tags to have multiple names. We can tag the release as x.y.z-rc, go through the voting process, etc. and then alias the tag to x.y.z and leave both of them there for posterity. That way, automated tools can just ignore all tags ending in -rc and when the /real/ x.y.z tag is available, that can trigger whatever process they want to follow. WDYT? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Tomcat 8.5.82
I personally like it when all three streams are updated at the same time, but I'm flexible. :-) Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Christopher Schultz > Sent: Thursday, July 21, 2022 7:20 AM > To: Tomcat Developers List > Subject: Tomcat 8.5.82 > > All, > > I was on holiday last week and will be out again today through Monday. > Looking at the changelog for 8.5.x, I don't see anything pressing[1], so I'm > thinking of just waiting for August to kind of reset the clock on releases > back > to the beginning(ish) of each month. > > Please let me know in the next 3-4 hours if anyone disagrees and I'll roll the > release and put it out for a vote before I leave. > > Thanks, > -chris > > [1] The only "important" thing is an upgrade of bundled OpenSSL for > Windows users, but they can grab an updated tcnative release if necessary. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional > commands, e-mail: dev-h...@tomcat.apache.org
Re: Delay between release tags and announcement
чт, 21 июл. 2022 г. в 15:23, Christopher Schultz : > > Nemo, Mark, > > On 7/21/22 04:06, Mark Thomas wrote: > > On 21/07/2022 07:06, Nemo wrote: > > > > > > > > Generally, I'd strongly discourage anyone from assuming that GitHub tag > > == ASF release. > > I generally agree with Mark, here, with one caveat: > > It would be very easy for our release tags to have multiple names. We > can tag the release as x.y.z-rc, go through the voting process, etc. and > then alias the tag to x.y.z and leave both of them there for posterity. > That way, automated tools can just ignore all tags ending in -rc and > when the /real/ x.y.z tag is available, that can trigger whatever > process they want to follow. > 1. I see no need to change the release process to be more complex, but it is up to release managers to decide if they want additional work. Changing the release process as Christopher proposes is doable for Tomcat, as long as it is built with Apache Ant, but it will result in lingering *-rc tags in the repository. Those add little value, but add some notable clutter. Changing the process for the Tomcat Migration Tool for Jakarta EE that is built with Apache Maven would be harder, as it contradicts with how Maven Release Plugin works. Personally I think that a tool that relies on GitHub tags is just broken. 2. If one wants to track the release date: When a release of Apache Tomcat is published, a) the DOAP file is updated, https://tomcat.apache.org/doap_Tomcat.rdf b) the release is published to dist.apache.org and becomes available via CDN c) artifacts are published to the Maven Central d) a release announcement is sent to annou...@tomcat.apache.org and to some other mailing lists. An automated tool may track any one of those. If one wants a release date, then a), c) and b) are available. The DOAP file (a)) is designed to be used by tools, but is less reliable than c) and b). An announcement at the front page of tomcat.apache.org and a changelog file also have the date. 3. GitHub itself makes a difference between "tags" and "releases". For Apache Tomcat project the GitHub is essentially a mirror. It mirrors the tags from the official ASF git repository. We do not publish "releases" there. https://github.com/apache/tomcat/releases 4. BTW I frequently see that in other projects a build date (signature date in signed Windows installers) and announcement date are different. E.g. OpenJDK. When I used builds from Oracle, there could be 1-2 week difference between apparent build date and the official announcement. E.g. Mozilla Firefox: - https://www.mozilla.org/en-US/firefox/102.0.1/releasenotes/ says Firefox 102.0.1 was released on July 6, 2022 and that is the official date. - The digital signature of "Firefox Setup 102.0.1.exe" installer is from July 5. - Files at https://ftp.mozilla.org/pub/firefox/releases/102.0.1/ are of July 5. For Firefox 101.0 the difference is more noticeable: May 31 (the official date) vs May 27 (signature) vs May 30 (files). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] New: Pound sign £ in passwords do not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 Bug ID: 66174 Summary: Pound sign £ in passwords do not work with LDAP realm Product: Tomcat 9 Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: mklinc...@yahoo.com Target Milestone: - There is the old post in the mailing lists about this problem but the issue is still confirmed. https://www.mail-archive.com/users@tomcat.apache.org/msg07977.html When a user in LDAP realm (MS Active Directory in my case and openldap in the case described in the mailing archive) has the pound sign in the password, the basic authentication does not work. Removing the pound sign from the password resolves the issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] Pound sign £ in passwords does not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 Mark Klinchin changed: What|Removed |Added Summary|Pound sign £ in passwords |Pound sign £ in passwords |do not work with LDAP realm |does not work with LDAP ||realm -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-jakartaee-migration] branch main updated (23513a5 -> 34d7c72)
This is an automated email from the ASF dual-hosted git repository. kkolinko pushed a change to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git from 23513a5 Include CHANGES.MD in src distro new 0f77a66 POM File - Followup to "[maven-release-plugin] prepare for next development iteration". Update SCM tag. new 8bc5c03 POM File - Sorted the contents. new 34d7c72 Copyright - Added an inceptionYear element to the POM file. Updated copyright year in the NOTICE to start with 2020. The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: NOTICE.txt | 2 +- pom.xml| 52 ++-- 2 files changed, 27 insertions(+), 27 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-jakartaee-migration] 03/03: Copyright - Added an inceptionYear element to the POM file. Updated copyright year in the NOTICE to start with 2020.
This is an automated email from the ASF dual-hosted git repository.
kkolinko pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
commit 34d7c72aa0eea3d403b287b10e92cdcead0676c7
Author: Konstantin Kolinko
AuthorDate: Thu Jul 21 19:38:29 2022 +0300
Copyright - Added an inceptionYear element to the POM file. Updated
copyright year in the NOTICE to start with 2020.
Initial commits in this repository and the tag for version 0.0.1 were on
January 13th 2020.
Though there was a discussion on the dev@ mailing list that mentioned it
earlier
("Proposed plan for Tomcat 10", December 16th 2019)
https://lists.apache.org/thread/8yjg6t383jzdz7k1d1zwzgtvwlt8xjd7
JSTL JARs in Tomcat 10.0 were converted with this tool on January 13th 2020.
https://lists.apache.org/thread/g9zfp511of0hjknm6s9qon40gjdht6w8
https://lists.apache.org/thread/m27zpp3xsz39mzqky21fyxcs6cbr12zy
https://github.com/apache/tomcat/commit/f796b98813d4b12f825276a9a353bf498c64d526
The commit f796b98 above apparently was first authored on December 16th
2019 (according to its "Date" header),
but amended and committed on January 13th 2020.
---
NOTICE.txt | 2 +-
pom.xml| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/NOTICE.txt b/NOTICE.txt
index c0daed6..0f32ebb 100644
--- a/NOTICE.txt
+++ b/NOTICE.txt
@@ -1,5 +1,5 @@
Apache Tomcat migration tool for Jakarta EE
-Copyright 2022 The Apache Software Foundation
+Copyright 2020-2022 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (https://www.apache.org/).
\ No newline at end of file
diff --git a/pom.xml b/pom.xml
index 6231fe1..6d06ed6 100644
--- a/pom.xml
+++ b/pom.xml
@@ -34,6 +34,8 @@
Tomcat 10 which implements Jakarta EE 9.
https://tomcat.apache.org
+ 2020
+
Apache Tomcat Announce List
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-jakartaee-migration] 02/03: POM File - Sorted the contents.
This is an automated email from the ASF dual-hosted git repository. kkolinko pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git commit 8bc5c038f2125292f47fe87ad51695c3d978bbc8 Author: Konstantin Kolinko AuthorDate: Thu Jul 21 18:17:23 2022 +0300 POM File - Sorted the contents. Applied sortpom-maven-plugin. The command: mvn com.github.ekryd.sortpom:sortpom-maven-plugin:3.2.0:sort -Dsort.expandEmptyElements=false -Dsort.spaceBeforeCloseEmptyElement -Dsort.predefinedSortOrder=recommended_2008_06 --- pom.xml | 50 -- 1 file changed, 24 insertions(+), 26 deletions(-) diff --git a/pom.xml b/pom.xml index 8da4004..6231fe1 100644 --- a/pom.xml +++ b/pom.xml @@ -17,7 +17,7 @@ --> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 - + org.apache apache @@ -26,14 +26,12 @@ org.apache.tomcat jakartaee-migration - Apache Tomcat Migration Tool for Jakarta EE 1.0.2-SNAPSHOT - - -The aim of the tool is to take a web application written for Java EE 8 that + Apache Tomcat Migration Tool for Jakarta EE + + The aim of the tool is to take a web application written for Java EE 8 that runs on Apache Tomcat 9 and convert it automatically so it runs on Apache -Tomcat 10 which implements Jakarta EE 9. - +Tomcat 10 which implements Jakarta EE 9. https://tomcat.apache.org @@ -56,9 +54,16 @@ users-unsubscr...@tomcat.apache.org us...@tomcat.apache.org https://lists.apache.org/list.html?us...@tomcat.apache.org - + - + + + scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git + scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git +main + https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git + + 8 8 @@ -98,20 +103,13 @@ - - scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git - scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git - https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git -main - - -src/main/resources true +src/main/resources - + @@ -137,14 +135,14 @@ create-test-jars -process-test-classes run +process-test-classes - - + + @@ -160,15 +158,15 @@ - + - + - + @@ -200,10 +198,10 @@ attach-sources -verify jar-no-fork +verify @@ -228,10 +226,10 @@ make-assembly -package single +package src/assembly/bin.xml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-jakartaee-migration] 01/03: POM File - Followup to "[maven-release-plugin] prepare for next development iteration". Update SCM tag.
This is an automated email from the ASF dual-hosted git repository.
kkolinko pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
commit 0f77a66e2a8635fdbbbd10f7432661edba0e7d61
Author: Konstantin Kolinko
AuthorDate: Thu Jul 21 17:47:49 2022 +0300
POM File - Followup to "[maven-release-plugin] prepare for next development
iteration". Update SCM tag.
Updated the value of the scm/tag element.
Looking at how it was before tagging release 1.0.1, it was "HEAD" here.
Using the branch name ("main") seems to be more correct.
---
pom.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pom.xml b/pom.xml
index 76c8cce..8da4004 100644
--- a/pom.xml
+++ b/pom.xml
@@ -102,7 +102,7 @@
scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
scm:git:https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git
https://gitbox.apache.org/repos/asf?p=tomcat-jakartaee-migration.git
-1.0.1
+main
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Delay between release tags and announcement
Konstantin, On 7/21/22 09:56, Konstantin Kolinko wrote: чт, 21 июл. 2022 г. в 15:23, Christopher Schultz : Nemo, Mark, On 7/21/22 04:06, Mark Thomas wrote: On 21/07/2022 07:06, Nemo wrote: Generally, I'd strongly discourage anyone from assuming that GitHub tag == ASF release. I generally agree with Mark, here, with one caveat: It would be very easy for our release tags to have multiple names. We can tag the release as x.y.z-rc, go through the voting process, etc. and then alias the tag to x.y.z and leave both of them there for posterity. That way, automated tools can just ignore all tags ending in -rc and when the /real/ x.y.z tag is available, that can trigger whatever process they want to follow. 1. I see no need to change the release process to be more complex, but it is up to release managers to decide if they want additional work. Changing the release process as Christopher proposes is doable for Tomcat, as long as it is built with Apache Ant, but it will result in lingering *-rc tags in the repository. Those add little value, but add some notable clutter. Meh. No more than having a large number of releases. Changing the process for the Tomcat Migration Tool for Jakarta EE that is built with Apache Maven would be harder, as it contradicts with how Maven Release Plugin works. Personally I think that a tool that relies on GitHub tags is just broken. +1 Anyone can tag anything at any time for any reason. A new tag == trigger a build pipeline that causes new releases of downstream projects to be built and released? Wow. What happens if the release vote doesn't pass and we remove the tag? It seems very fragile to me. 2. If one wants to track the release date: When a release of Apache Tomcat is published, a) the DOAP file is updated, https://tomcat.apache.org/doap_Tomcat.rdf b) the release is published to dist.apache.org and becomes available via CDN c) artifacts are published to the Maven Central *This* should probably be the trigger that causes all that downstream stuff to occur. We won't upload anything to Maven Central that isn't official. d) a release announcement is sent to annou...@tomcat.apache.org and to some other mailing lists. An automated tool may track any one of those. If one wants a release date, then a), c) and b) are available. The DOAP file (a)) is designed to be used by tools, but is less reliable than c) and b). An announcement at the front page of tomcat.apache.org and a changelog file also have the date. 3. GitHub itself makes a difference between "tags" and "releases". For Apache Tomcat project the GitHub is essentially a mirror. It mirrors the tags from the official ASF git repository. We do not publish "releases" there. https://github.com/apache/tomcat/releases I don't know what it would take to "release" on GH. If it's not too much work, I'd be willing to do it, particularly if it can be mostly scripted. 4. BTW I frequently see that in other projects a build date (signature date in signed Windows installers) and announcement date are different. E.g. OpenJDK. When I used builds from Oracle, there could be 1-2 week difference between apparent build date and the official announcement. E.g. Mozilla Firefox: - https://www.mozilla.org/en-US/firefox/102.0.1/releasenotes/ says Firefox 102.0.1 was released on July 6, 2022 and that is the official date. - The digital signature of "Firefox Setup 102.0.1.exe" installer is from July 5. - Files at https://ftp.mozilla.org/pub/firefox/releases/102.0.1/ are of July 5. For Firefox 101.0 the difference is more noticeable: May 31 (the official date) vs May 27 (signature) vs May 30 (files). Thanks for your thoughts, K. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] Pound sign £ in passwords does not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 Mark Klinchin changed: What|Removed |Added CC||mklinc...@yahoo.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] Pound sign £ in passwords does not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 --- Comment #1 from Christopher Schultz --- Can you confirm that you can successfully authenticate with OpenLDAP using some other utility e.g. ldapsearch? I'm wondering if this is a Tomcat issue or an OpenLDAP issue. If you enable logging (hmm not sure if we log the password at TRACE level), can you confirm that Tomcat has the password without being garbled by the browser/web server/request encoding in some way? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] Pound sign £ in passwords does not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 Konstantin Kolinko changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Konstantin Kolinko --- You need to provide configuration and steps to reproduce this issue, and exact version number of Tomcat where this issue is observed. Overall, this sounds like either a configuration issue, and configuration issues are to be discussed on the Tomcat Users' mailing list, not here. Note that the BASIC authentication is limited to ISO-8859-1 charset by default. Testing with Apache Tomcat 9.0.65, I can successfully log in into the manager web application using the pound character as a password, if I reconfigure the BasicAuthenticator in that web application to use UTF-8. It can be done by inserting the following line into the webapps/manager/META-INF/context.xml file. For reference, see https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Basic_Authenticator_Valve I wonder whether better documentation may be needed somewhere. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Updated HTTP specifications
Hi! I updated the list of specifications in our wiki with new versions of HTTP specifications. Those were published in June 2022, along with HTTP./3. https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-HTTP,HTTP/2 RFC 9110 (June 2022) - HTTP Semantics RFC 9111 (June 2022) - HTTP Caching RFC 9112 (June 2022) - HTTP/1.1 RFC 9113 (June 2022) - HTTP/2 RFC 9114 (June 2022) - HTTP/3 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66175] New: Consider changing BasicAuthenticator to default to charset="UTF"
https://bz.apache.org/bugzilla/show_bug.cgi?id=66175 Bug ID: 66175 Summary: Consider changing BasicAuthenticator to default to charset="UTF" Product: Tomcat 10 Version: 10.1.0-M17 Hardware: PC Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com Target Milestone: -- A support for using UTF-8 with BasicAuthenticator has already been implemented since Tomcat 9.0.0 (in September 2017) - Bug 61280. I think we may consider to change the default in BasicAuthenticator to be UTF-8 nowadays, for Tomcat 10.1 onwards. Testing with Firefox 102 (see my comment in bug 66174), it does accept the charset=UTF-8 parameter in the value of a WWW-Authenticate response header. Moreover, regardless of whether such charset parameter was present is a response header, Firefox encodes the credentials of a subsequent request with UTF-8. The BasicAuthenticator by default expects ISO-8859-1 and cannot decode them. - Tested with Apache Tomcat 9.0.65 and the manager web application. See also: Bug 66174 https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding#CharacterEncoding-Q10 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] orbea opened a new pull request, #13: native: Update for libressl 3.5
orbea opened a new pull request, #13: URL: https://github.com/apache/tomcat-native/pull/13 Tested with libressl-3.5.3 on Gentoo using the libressl overlay (https://github.com/gentoo/libressl). Alternatively the code for older libressl versions could be removed, either way it doesn't really matter to me. I'm also not sure what is the last libressl version to work with tomcat-native. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] orbea opened a new pull request, #14: native: Fix the build with rlibtool
orbea opened a new pull request, #14: URL: https://github.com/apache/tomcat-native/pull/14 When building tomcat-native with slibtool using the rlibtool symlink the build will fail. This is because rlibtool requires the generated libtool script to determine if the build is shared, static or both. Gentoo bug: https://bugs.gentoo.org/778914 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
