Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] wrote: billbarker2004/11/21 22:42:46 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Reverting reversion of patch ;-) Sorry for the trouble ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Bill Barker wrote: Bill Barker wrote: [EMAIL PROTECTED] wrote: billbarker2004/11/19 19:04:28 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: If we are in the error state, we aren't going to keep-alive. So don't lie to the UA that we are. Fix for Bug #32292 -1. I disagree with this change, sorry. We are going to keepalive in this case (anything which isn't a status drop, which is the whole point). The error flag can be set by a sendError, which could send any status code. You're vote would be more convincing if anything that you said was actually true ;-). We're note going to keepalive, and you can't set if from sendError. It's not true ? Did I miss something ? The thing with sendError and not closing the connection is that often sendError is used to trigger pretty standard error pages. This is the 'error' flag in Http11Processor. It's set in various 'catch' blocks, and for a couple of places where the request can't be parsed (mostly the Host header and the Protocol). In particular, it isn't visible to the Response :). Once it is set, it is never cleared, and being set causes the Processor to drop out of the keep-alive loop. Thanks for the explanation (you don't have to revert a patch right away, BTW). As the error flag is used in the loop, and does not depend on sendError, then the patch was fine. I didn't look in detail at that code for a while, and I forgot the subtelties. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, November 20, 2004 1:17 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: billbarker2004/11/19 19:04:28 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: If we are in the error state, we aren't going to keep-alive. So don't lie to the UA that we are. Fix for Bug #32292 -1. I disagree with this change, sorry. We are going to keepalive in this case (anything which isn't a status drop, which is the whole point). The error flag can be set by a sendError, which could send any status code. You're vote would be more convincing if anything that you said was actually true ;-). We're note going to keepalive, and you can't set if from sendError. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Bill Barker wrote: [EMAIL PROTECTED] wrote: billbarker2004/11/19 19:04:28 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: If we are in the error state, we aren't going to keep-alive. So don't lie to the UA that we are. Fix for Bug #32292 -1. I disagree with this change, sorry. We are going to keepalive in this case (anything which isn't a status drop, which is the whole point). The error flag can be set by a sendError, which could send any status code. You're vote would be more convincing if anything that you said was actually true ;-). We're note going to keepalive, and you can't set if from sendError. It's not true ? Did I miss something ? The thing with sendError and not closing the connection is that often sendError is used to trigger pretty standard error pages. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, November 20, 2004 2:40 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Bill Barker wrote: [EMAIL PROTECTED] wrote: billbarker2004/11/19 19:04:28 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: If we are in the error state, we aren't going to keep-alive. So don't lie to the UA that we are. Fix for Bug #32292 -1. I disagree with this change, sorry. We are going to keepalive in this case (anything which isn't a status drop, which is the whole point). The error flag can be set by a sendError, which could send any status code. You're vote would be more convincing if anything that you said was actually true ;-). We're note going to keepalive, and you can't set if from sendError. It's not true ? Did I miss something ? The thing with sendError and not closing the connection is that often sendError is used to trigger pretty standard error pages. This is the 'error' flag in Http11Processor. It's set in various 'catch' blocks, and for a couple of places where the request can't be parsed (mostly the Host header and the Protocol). In particular, it isn't visible to the Response :). Once it is set, it is never cleared, and being set causes the Processor to drop out of the keep-alive loop. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
From: Remy Maucherat [mailto:[EMAIL PROTECTED] The issue is that there's no value in this: it would likely take 5 minutes for an attacker to figure out the webserver is running Tomcat. The Server header is maybe the less visible of them (and gives little information when compared to the others). So why bother about this ? (that's my point) Because users want the functionality. If it can be done without hitting performance, why not do it? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Mark Thomas wrote: From: Remy Maucherat [mailto:[EMAIL PROTECTED] The issue is that there's no value in this: it would likely take 5 minutes for an attacker to figure out the webserver is running Tomcat. The Server header is maybe the less visible of them (and gives little information when compared to the others). So why bother about this ? (that's my point) Because users want the functionality. Cool. Let the morons rule, then ;) If it can be done without hitting performance, why not do it? Because useless functionality is bloat, and should not be added. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] wrote:
markt 2004/08/23 12:29:35
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Fix bug 16254 - Server header appears twice after a call to response.setHeader()
Revision ChangesPath
1.105 +3 -1 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.104
retrieving revision 1.105
diff -u -r1.104 -r1.105
--- Http11Processor.java 21 Aug 2004 02:51:37 - 1.104
+++ Http11Processor.java 23 Aug 2004 19:29:35 - 1.105
@@ -1511,7 +1511,9 @@
}
// Add server header
-response.addHeader(Server, Constants.SERVER);
+if (! response.containsHeader(Server)){
+response.addHeader(Server, Constants.SERVER);
+}
As I said way back then, I dislike this patch. I will now revert it (as
Scott pointed out, the X-Powered-By header is used for that kind of
purpose).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
This is an often asked for feature. My pref is for it to be a configuration in the Connector. Then the only added overhead is in during init. For example ... protected serverHeader = Constants.SERVER; ... setServerHeader() ... getServerHeader() ... ... response.addHeader(Server, serverHeader); ?? -Tim Remy Maucherat wrote: [EMAIL PROTECTED] wrote: markt 2004/08/23 12:29:35 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Fix bug 16254 - Server header appears twice after a call to response.setHeader() Revision ChangesPath 1.105 +3 -1 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
I disalike patches which cause a performance hit for the sole interest of embeddors who don't contribute anything. Agreed. But this wasn't the reasoning behind the patch. From the original bug report (16254) I believe the reporter had a security motive. To repeat some of my earlier comments on this change: quote ...section 14.38 of RFC 2616 does state spec-quote Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option. /spec-quote The default doesn't include a specific version but I think allowing it to be overridden is more inline with the quote above. Further, I couldn't see anything in the servlet spec that limits the use of response.setHeader() to a subset of HTTP headers. The patch I applied was based on the handling of the date header immediately previously in the same class. /quote My position remains that the above reasons are sufficient justification for the patch to remain. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Mark Thomas wrote: I disalike patches which cause a performance hit for the sole interest of embeddors who don't contribute anything. Agreed. But this wasn't the reasoning behind the patch. From the original bug report (16254) I believe the reporter had a security motive. To repeat some of my earlier comments on this change: quote ...section 14.38 of RFC 2616 does state spec-quote Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option. /spec-quote The default doesn't include a specific version but I think allowing it to be overridden is more inline with the quote above. Further, I couldn't see anything in the servlet spec that limits the use of response.setHeader() to a subset of HTTP headers. There are a lot of protocol specific headers that you cannot set using that. The patch I applied was based on the handling of the date header immediately previously in the same class. /quote You are quite right that the date header special handling should probaly go as well ;) My position remains that the above reasons are sufficient justification for the patch to remain. My position remains the same as well. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
From: Remy Maucherat [mailto:[EMAIL PROTECTED] My position remains that the above reasons are sufficient justification for the patch to remain. My position remains the same as well. Making the value of the server header configurable, as per Tim's suggestion earlier in this thread, would meet the user requirement described in bug 16254 which is my main concern. Providing this is done in a way that doesn't impact performance, would you find this an acceptable compromise? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Mark Thomas wrote: Making the value of the server header configurable, as per Tim's suggestion earlier in this thread, would meet the user requirement described in bug 16254 which is my main concern. Providing this is done in a way that doesn't impact performance, would you find this an acceptable compromise? The issue is that there's no value in this: it would likely take 5 minutes for an attacker to figure out the webserver is running Tomcat. The Server header is maybe the less visible of them (and gives little information when compared to the others). So why bother about this ? (that's my point) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] wrote: markt 2004/08/23 12:29:35 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Fix bug 16254 - Server header appears twice after a call to response.setHeader() I don't see any use for this. IMO, the server header should reflect the HTTP stack. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 23, 2004 1:01 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: markt 2004/08/23 12:29:35 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Fix bug 16254 - Server header appears twice after a call to response.setHeader() I don't see any use for this. IMO, the server header should reflect the HTTP stack. I agree with Remy. IMO, a better patch would be s/addHeader/setHeader/. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
The reporter of the bug was trying to use a filter to override the contents of the server header and set it to no name. They didn't say so, but I am guessing there was a security motive behind their actions. Mark -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, August 23, 2004 9:01 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/ht tp11 Http11Processor.java [EMAIL PROTECTED] wrote: markt 2004/08/23 12:29:35 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Fix bug 16254 - Server header appears twice after a call to response.setHeader() I don't see any use for this. IMO, the server header should reflect the HTTP stack. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Mark Thomas wrote: The reporter of the bug was trying to use a filter to override the contents of the server header and set it to no name. They didn't say so, but I am guessing there was a security motive behind their actions. Well, that's not very convincing. Can't they recompile if they want to do specific stuff ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
From: Bill Barker [mailto:[EMAIL PROTECTED] - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 23, 2004 1:01 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: markt 2004/08/23 12:29:35 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Fix bug 16254 - Server header appears twice after a call to response.setHeader() I don't see any use for this. IMO, the server header should reflect the HTTP stack. I agree with Remy. IMO, a better patch would be s/addHeader/setHeader/. Not sure what you mean by s/addHeader/setHeader/. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
From: Remy Maucherat [mailto:[EMAIL PROTECTED] Mark Thomas wrote: The reporter of the bug was trying to use a filter to override the contents of the server header and set it to no name. They didn't say so, but I am guessing there was a security motive behind their actions. Well, that's not very convincing. It was only a guess at a reason, based on a short bug report. However section 14.38 of RFC 2616 does state quote Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option. /quote The default doesn't include a specific version but I think allowing it to be overridden is more inline with the quote above. Further, I couldn't see anything in the servlet spec that limits the use of response.setHeader() to a subset of HTTP headers. The patch I applied was based on the handling of the date header immediately previously in the same class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] wrote:
luehe 2004/07/27 17:43:44
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Fixed Bugtraq 6152759 (Default charset not included in Content-Type
response header if no char encoding was specified).
According to the Servlet 2.4 spec, calling:
ServletResponse.setContentType(text/html);
must yield these results:
ServletResponse.getContentType() - text/html
Content-Type response header - text/html;charset=ISO-8859-1
Notice the absence of a charset in the result of getContentType(), but
its presence (set to the default ISO-8859-1) in the Content-Type
response header.
Tomcat is currently not including the default charset in the
Content-Type response header if no char encoding was specified.
Revision ChangesPath
1.101 +1 -1 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.100
retrieving revision 1.101
diff -u -r1.100 -r1.101
--- Http11Processor.java 1 Jun 2004 14:34:22 - 1.100
+++ Http11Processor.java 28 Jul 2004 00:43:44 - 1.101
@@ -1450,7 +1450,7 @@
if (!entityBody) {
response.setContentLength(-1);
} else {
-String contentType = response.getContentType();
+String contentType = response.getContentTypeResponseHeader();
if (contentType != null) {
headers.setValue(Content-Type).setString(contentType);
}
Cool. So after all the efforts I'm doing to optimize, you casually add
GC, because the servlet API is completely stupid ?
So -1 for your patch: you need to rework it. I also didn't read all that
funny stuff in the specification, so where does it come from ? ;)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Chère Cliente, Cher Client, Merci de nous avoir contactés. Vous venez d'envoyer un message à une adresse ne permettant pas de recevoir d'e-mail. Pour trouver les réponses à vos questions sur vos commandes, sur les produits, sur le site, consultez nos pages d'aide en ligne en cliquant sur : http://www.fnac.com/Help/A01.asp Vous pouvez également suivre en direct l'évolution de vos commandes en cours, en consultant la rubrique Vos Commandes en un clin d'oeil en cliquant sur : https://www.fnac.com/Account/Profil/default.asp Nous espérons que ces pages vous apporteront toutes les informations nécessaires. Dans le cas contraire, vous pouvez nous contacter par e-mail en cliquant sur le lien : http://www.fnac.com/Service_Client/FnacSUGG.asp Merci de votre fidélité a www.fnac.com Très cordialement, L'équipe Fnac.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Service Client Fnac.com wrote: Chère Cliente, Cher Client, Merci de nous avoir contactés. Vous venez d'envoyer un message à une adresse ne permettant pas de recevoir d'e-mail. Pour trouver les réponses à vos questions sur vos commandes, sur les produits, sur le site, consultez nos pages d'aide en ligne en cliquant sur : http://www.fnac.com/Help/A01.asp Vous pouvez également suivre en direct l'évolution de vos commandes en cours, en consultant la rubrique Vos Commandes en un clin d'oeil en cliquant sur : https://www.fnac.com/Account/Profil/default.asp Nous espérons que ces pages vous apporteront toutes les informations nécessaires. Dans le cas contraire, vous pouvez nous contacter par e-mail en cliquant sur le lien : http://www.fnac.com/Service_Client/FnacSUGG.asp Merci de votre fidélité a www.fnac.com Très cordialement, L'équipe Fnac.com This account is still registered to tomcat-dev ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Chère Cliente, Cher Client, Merci de nous avoir contactés. Vous venez d'envoyer un message à une adresse ne permettant pas de recevoir d'e-mail. Pour trouver les réponses à vos questions sur vos commandes, sur les produits, sur le site, consultez nos pages d'aide en ligne en cliquant sur : http://www.fnac.com/Help/A01.asp Vous pouvez également suivre en direct l'évolution de vos commandes en cours, en consultant la rubrique Vos Commandes en un clin d'oeil en cliquant sur : https://www.fnac.com/Account/Profil/default.asp Nous espérons que ces pages vous apporteront toutes les informations nécessaires. Dans le cas contraire, vous pouvez nous contacter par e-mail en cliquant sur le lien : http://www.fnac.com/Service_Client/FnacSUGG.asp Merci de votre fidélité a www.fnac.com Très cordialement, L'équipe Fnac.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Henri Gomez wrote: Service Client Fnac.com wrote: Chère Cliente, Cher Client, Merci de nous avoir contactés. Vous venez d'envoyer un message à une adresse ne permettant pas de recevoir d'e-mail. Pour trouver les réponses à vos questions sur vos commandes, sur les produits, sur le site, consultez nos pages d'aide en ligne en cliquant sur : http://www.fnac.com/Help/A01.asp Vous pouvez également suivre en direct l'évolution de vos commandes en cours, en consultant la rubrique Vos Commandes en un clin d'oeil en cliquant sur : https://www.fnac.com/Account/Profil/default.asp Nous espérons que ces pages vous apporteront toutes les informations nécessaires. Dans le cas contraire, vous pouvez nous contacter par e-mail en cliquant sur le lien : http://www.fnac.com/Service_Client/FnacSUGG.asp Merci de votre fidélité a www.fnac.com Très cordialement, L'équipe Fnac.com This account is still registered to tomcat-dev ? It came back :( I tried banning it this time (I'm learning the mailing list comments at the same time). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: Cool. So after all the efforts I'm doing to optimize, you casually add GC, because the servlet API is completely stupid ? So -1 for your patch: you need to rework it. I also didn't read all that funny stuff in the specification, so where does it come from ? ;) I thought about it some more, and in addition to the performance problem, it would lead to adding charset even for binaries. We already found out that this way very bad (in addition to being meaningless, it breaks some clients such as Acrobat which simply does a check on the MIME type without removing the charset, which is rather logical since they're dealing with binaries) - this was some unintended behavior in some 4.1.x release (if I remember well, it was introduced by you already: you do like charset related issues ;) ). So what I suggest is that you send that you send that as feedback to the servlet API, and that they put a small errata for the specification. -1 for implementing the requirements of the specificatrion (although I can't find them anywhere ;) ) to the letter right now, as they are broken (I didn't dislike the previous behavior, so I want it to remain). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy, Remy Maucherat wrote: Remy Maucherat wrote: Cool. So after all the efforts I'm doing to optimize, you casually add GC, because the servlet API is completely stupid ? So -1 for your patch: you need to rework it. I also didn't read all that funny stuff in the specification, so where does it come from ? ;) I thought about it some more, and in addition to the performance problem, it would lead to adding charset even for binaries. We already found out that this way very bad (in addition to being meaningless, it breaks some clients such as Acrobat which simply does a check on the MIME type without removing the charset, which is rather logical since they're dealing with binaries) - this was some unintended behavior in some 4.1.x release (if I remember well, it was introduced by you already: you do like charset related issues ;) ). yes, sorry, I had forgotten about that case. Believe, I didn't commit yesterday's patch simply because I don't have anything better to do. It's come up as a compliance issue which had been masked by an unrelated problem that was fixed. So what I suggest is that you send that you send that as feedback to the servlet API, and that they put a small errata for the specification. -1 for implementing the requirements of the specificatrion (although I can't find them anywhere ;) ) to the letter right now, as they are broken (I didn't dislike the previous behavior, so I want it to remain). ServletResponse.setCharacterEncoding/setContentType/setLocale... * pContainers must communicate the character encoding used for * the servlet response's writer to the client if the protocol * provides a way for doing so. In the case of HTTP, the character * encoding is communicated as part of the codeContent-Type/code * header for text media types. Note that the character encoding * cannot be communicated via HTTP headers if the servlet does not * specify a content type; however, it is still used to encode text * written via the servlet response's writer. Reason: Many browsers let the user choose which encoding to apply to responses that don't declare their encoding, which will result in data corruption if the response was encoded in ISO-8859-1 and the user picks an incompatible encoding. ServletResponse.getContentType...: * If no character encoding has been specified, the * charset parameter is omitted. Reason: Allow setLocale() to set the response's char encoding (corresponding to the locale) if the char encoding has not already been set by setContentType() or setCharacterEncoding(). You can find corresponding wordings in the servlet spec. Therefore, we need to add a charset to the Content-Type response header if: - no response encoding has been specified (ie., the return value of ServletResponse.getContentType() has no charset), and - the response is using a writer My patch did not check for the latter. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Jan Luehe wrote: yes, sorry, I had forgotten about that case. Believe, I didn't commit yesterday's patch simply because I don't have anything better to do. It's come up as a compliance issue which had been masked by an unrelated problem that was fixed. I thought the issue caused enough trouble last time ;) I remember we got a huge amount of bug reports on that. So what I suggest is that you send that you send that as feedback to the servlet API, and that they put a small errata for the specification. ServletResponse.setCharacterEncoding/setContentType/setLocale... * pContainers must communicate the character encoding used for * the servlet response's writer to the client if the protocol * provides a way for doing so. In the case of HTTP, the character * encoding is communicated as part of the codeContent-Type/code * header for text media types. Note that the character encoding * cannot be communicated via HTTP headers if the servlet does not * specify a content type; however, it is still used to encode text * written via the servlet response's writer. Reason: Many browsers let the user choose which encoding to apply to responses that don't declare their encoding, which will result in data corruption if the response was encoded in ISO-8859-1 and the user picks an incompatible encoding. The user can still manually override the charset on its client if it wants to do so. I don't see how the specified behavior fixes anything. ServletResponse.getContentType...: * If no character encoding has been specified, the * charset parameter is omitted. Reason: Allow setLocale() to set the response's char encoding (corresponding to the locale) if the char encoding has not already been set by setContentType() or setCharacterEncoding(). You can find corresponding wordings in the servlet spec. Therefore, we need to add a charset to the Content-Type response header if: - no response encoding has been specified (ie., the return value of ServletResponse.getContentType() has no charset), and - the response is using a writer My patch did not check for the latter. Well, this would be a big improvement already (the implementation is inefficient, also, but either Bill or me can rework it). People who wanted to generate PDFs from JSPs had trouble (but it made sense), now it'll be worse. This doesn't seem very useable overall. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] a écrit : remm2004/01/14 03:12:50 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - Correctly initialize arrays (Java is not C ;-) ). Arg, my fault :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Henri Gomez wrote: [EMAIL PROTECTED] a écrit : remm2004/01/14 03:12:50 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - Correctly initialize arrays (Java is not C ;-) ). Arg, my fault :) The feature works very well. Very good :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat a écrit : Henri Gomez wrote: [EMAIL PROTECTED] a écrit : remm2004/01/14 03:12:50 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - Correctly initialize arrays (Java is not C ;-) ). Arg, my fault :) The feature works very well. Very good :) Thanks, BTW it was needed by specs and also by respect to our great HTTPD 2.0 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I said it would be ok, yesterday, but I changed my mind, as this looks wrong. If Bill votes -1 to this, I'll change my vote to -1. I should start reverting my patch ;-) The problem is that this call is likely intended to allow users to build URLs to the server. Actually, this won't work, since the server may not be accessible with the connector hostname or port. What actually should be returned is what is in the Host header (HTTP/1.0 is a broken spec, since it can't possibly work when behind a reverse proxy). Otherwise, we're returning completely useless information to the user, and the getLocalPort is simply useless. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) -- Jeanfrancois Note: Compliant HTTP/1.1 clients must send correct Host header, and proxy servers are not allowed to modify them. 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-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I don't see how JK would set the localPort field (since the new action isn't handled yet), so I thought it would always return -1. Maybe I'm wrong, I didn't try it. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) I don't know, maybe you can talk to the Servlet spec people first to see what they have to say on this issue ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 HTH, Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 2.0 and JSTL 1.1 Details athttp://TheJSPBook.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 8:59 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) I said it would be ok, yesterday, but I changed my mind, as this looks wrong. If Bill votes -1 to this, I'll change my vote to -1. I'm fine with the patch (although not a great fan of getLocalPort :). The problem is that this call is likely intended to allow users to build URLs to the server. Actually, this won't work, since the server may not be accessible with the connector hostname or port. What actually should be returned is what is in the Host header (HTTP/1.0 is a broken spec, since it can't possibly work when behind a reverse proxy). Otherwise, we're returning completely useless information to the user, and the getLocalPort is simply useless. Users should be using getServerPort to build URLs to the server. The problem with yesterdays patch is that it broke getServerPort (which is defined to be the value of the Host header). I agree that getLocalPort is simply useless, but it's in the spec so we have to implement it :). About the only thing that it is good for is to grant rights to requests coming in on one connector, but not on another (which points to a bad design). Note: Compliant HTTP/1.1 clients must send correct Host header, and proxy servers are not allowed to modify them. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 9:47 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I don't see how JK would set the localPort field (since the new action isn't handled yet), so I thought it would always return -1. Maybe I'm wrong, I didn't try it. Yes, the JK connector is going to need some changes to support this. However they should be pretty minor. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) I don't know, maybe you can talk to the Servlet spec people first to see what they have to say on this issue ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Hans Bergsten wrote: Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Then today's commit implemented that behaviour except for getLocalName(0 which is still broken.Will fix it). Before getLocalPort() was calling getServerPort() (my mistake back in 03/05). I think the spec should be clarified with an example like this one ;-) Thanks for the clarification. -- Jeanfrancois HTH, Hans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Hans Bergsten wrote: Remy Maucherat wrote: [...] Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. The getLocalXXX() methods are intended to provide information about where the request was _recieved_ by the container, rather than where it was _sent_ by the client, which is useful information for some types of applications, for instance to detect if there's any vhosting involved. So proxying would be detected as vhosting. I think it would indicate if the server is a pure standalone server, but that's it. So you have three sets of methods for getting address/port info. * Where the request was received (server socket): getLocalName() getLocalPort() getLocalAddr() * Where the request was sent (Host header info): getServerName() getServerPort() * Where the request comes from (client socket): getRemoteName() getRemotePort() getRemoteAddr() With an HTTP/1.1 request with a Host header foo.com value, proxied through Apache to Tomcat listening on port 8005, from a client (or a proxy) at 4.62.132.17 (bar.com) port 1766, the methods should return these values: getLocalName() - localhost (or some other local interface) getLocalPort() - 8005 getLocalAddr() - 127.0.0.1 (or some other local interface) getServerName() - foo.com getServerPort() - 80 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 Without proxying through Apache, a Host header localhost:8080 value and Tomcat listening on port 8080, it would look like this instead: getLocalName() - localhost getLocalPort() - 8080 getLocalAddr() - 127.0.0.1 getServerName() - localhost getServerPort() - 8080 getRemoteName() - bar.com getRemotePort() - 1766 getRemoteAddr() - 4.62.132.17 This will likely confuse users a bit. If it's as intended, then fine :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here) Also we are doing something similar if http 1.0 is used (just above): // HTTP/1.0 // Default is what the socket tells us. Overriden if a host is // found/parsed request.setServerPort(socket.getLocalPort()); -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here) I don't remember. I think you should look into the version history. I will tomorrow. Also we are doing something similar if http 1.0 is used (just above): // HTTP/1.0 // Default is what the socket tells us. Overriden if a host is // found/parsed request.setServerPort(socket.getLocalPort()); It goes both ways. One possible explanation for that is that this code is much less used, and it never got fixed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here) I don't remember. I think you should look into the version history. I will tomorrow. It was added with version 1.23. Bill ? ;-) I've just realized that the sslSupport variable is no longer needed (so my fix needs to be cleaned). BTW the test I'm doing is: telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost In the servlet, I'm doing request.getLocalPort(), which always returns 80. But it works if I do telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost:8080 ;-) -- Jeanfrancois Also we are doing something similar if http 1.0 is used (just above): // HTTP/1.0 // Default is what the socket tells us. Overriden if a host is // found/parsed request.setServerPort(socket.getLocalPort()); It goes both ways. One possible explanation for that is that this code is much less used, and it never got fixed. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Jeanfrancois Arcand wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here) I don't remember. I think you should look into the version history. I will tomorrow. It was added with version 1.23. Bill ? ;-) I've just realized that the sslSupport variable is no longer needed (so my fix needs to be cleaned). BTW the test I'm doing is: telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost In the servlet, I'm doing request.getLocalPort(), which always returns 80. But it works if I do telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost:8080 ;-) Thanks for the example, I now remember the reason for the code. So I'll have to veto your patch. The rule for HTTP/1.1 is that: - it should use whatever is specified in the host header - it should return the protocol default otherwise, since this is the same as not specifying anything in the host header This comes from vhosting. serverName and serverPort must contain teh vhosting information. HTTP/1.0 doesn't have the host header, so the socket is used. Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket. Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here) I don't remember. I think you should look into the version history. I will tomorrow. It was added with version 1.23. Bill ? ;-) I've just realized that the sslSupport variable is no longer needed (so my fix needs to be cleaned). BTW the test I'm doing is: telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost In the servlet, I'm doing request.getLocalPort(), which always returns 80. But it works if I do telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost:8080 ;-) Thanks for the example, I now remember the reason for the code. So I'll have to veto your patch. The rule for HTTP/1.1 is that: - it should use whatever is specified in the host header - it should return the protocol default otherwise, since this is the same as not specifying anything in the host header This comes from vhosting. serverName and serverPort must contain teh vhosting information. HTTP/1.0 doesn't have the host header, so the socket is used. Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it. :-( OK I will revert the fix and see what I can do with the Servlet spec (and try to see if we can do something in another place that will not impact the current code). -- Jeanfrancois 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-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 01, 2003 12:44 PM Subject: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. -1 for the patch. It breaks NATs, proxies, etc. It also breaks the servlet-spec for ServletRequest.getServerPort. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
[EMAIL PROTECTED] a écrit :
hgomez 2003/10/01 00:54:09
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
More setters for gzip compression support.
Here is the correction for getRemoteAddr(), getRemoteHost(),
getRemotePort().
I detected that I got null instead of IP address while playing with
Coyote 2 HTTP 1.1 connector with Tomcat 3.3.2-dev.
Thanks to verify it didn't break anything with TC 4.1.x and 5.0.x :)
Also here is an example of gzip settings in Coyote2 Connector :
CoyoteConnector2 port=8081
secure=false
maxThreads=100
maxSpareThreads=50
minSpareThreads=10
compression=on
compressionMinSize=2048
noCompressionUserAgents=gozilla, reloo
compressableMimeType=text/html,text/xml /
Regards :-)
/**
@@ -885,29 +925,32 @@
} else if (actionCode == ActionCode.ACTION_REQ_HOST_ADDR_ATTRIBUTE) {
-if ((remoteAddr == null) (socket != null)) {
+if ((remoteAddr == null) (socket != null))
remoteAddr = socket.getInetAddress().getHostAddress();
-request.remoteAddr().setString(remoteAddr);
-}
+
+request.remoteAddr().setString(remoteAddr);
} else if (actionCode == ActionCode.ACTION_REQ_HOST_ATTRIBUTE) {
-if (remoteAddr == null) {
+if (remoteAddr == null)
remoteAddr = socket.getInetAddress().getHostAddress();
-request.remoteAddr().setString(remoteAddr);
-}
-if (remoteHost == null) {
+
+ request.remoteAddr().setString(remoteAddr);
+
+if (remoteHost == null)
remoteHost = socket.getInetAddress().getHostName();
-request.remoteHost().setString(remoteHost);
-}
-if (remotePort == -1){
+
+ request.remoteHost().setString(remoteHost);
+
+if (remotePort == -1)
remotePort = socket.getPort();
-request.setRemotePort(remotePort);
-}
-if (localAddr == null){
+
+request.setRemotePort(remotePort);
+
+if (localAddr == null)
localAddr = socket.getLocalAddress().getHostAddress();
- request.localAddr().setString(localAddr);
-}
+
+ request.localAddr().setString(localAddr);
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
if( sslSupport != null) {
@@ -1230,6 +1273,7 @@
request.getMimeHeaders().getValue(user-agent);
String userAgentValue = userAgentValueMB.toString();
+ // TODO: Use regexp instead of simple string compare (cf: Apache 2.x)
if (inStringArray(noCompressionUserAgents, userAgentValue))
return false;
}
-
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-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Henri Gomez wrote: [EMAIL PROTECTED] a écrit : hgomez 2003/10/01 00:54:09 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: More setters for gzip compression support. Here is the correction for getRemoteAddr(), getRemoteHost(), getRemotePort(). I detected that I got null instead of IP address while playing with Coyote 2 HTTP 1.1 connector with Tomcat 3.3.2-dev. Thanks to verify it didn't break anything with TC 4.1.x and 5.0.x :) Also here is an example of gzip settings in Coyote2 Connector : CoyoteConnector2 port=8081 secure=false maxThreads=100 maxSpareThreads=50 minSpareThreads=10 compression=on compressionMinSize=2048 noCompressionUserAgents=gozilla, reloo compressableMimeType=text/html,text/xml / Regards :-) I don't see a reason why it would be broken. The method call is likely redundant in TC 4.1/5.0, but it doesn't cause any performance problem, so I'm ok with the patch (except for the tabs, of course; can you remove them ?). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
Remy Maucherat a écrit : Henri Gomez wrote: [EMAIL PROTECTED] a écrit : hgomez 2003/10/01 00:54:09 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: More setters for gzip compression support. Here is the correction for getRemoteAddr(), getRemoteHost(), getRemotePort(). I detected that I got null instead of IP address while playing with Coyote 2 HTTP 1.1 connector with Tomcat 3.3.2-dev. Thanks to verify it didn't break anything with TC 4.1.x and 5.0.x :) Also here is an example of gzip settings in Coyote2 Connector : CoyoteConnector2 port=8081 secure=false maxThreads=100 maxSpareThreads=50 minSpareThreads=10 compression=on compressionMinSize=2048 noCompressionUserAgents=gozilla, reloo compressableMimeType=text/html,text/xml / Regards :-) I don't see a reason why it would be broken. The method call is likely redundant in TC 4.1/5.0, but it doesn't cause any performance problem, so I'm ok with the patch (except for the tabs, of course; can you remove them ?). Urg, bad Eclipse setup. I update asap :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java
I'm very strongly -1 on this. The o.a.coyote.Request should not have a
set/getSocket method for the simple reason that there is no reason that
Coyote should be assumed to be tied to a socket transport.
CertificatesValve doesn't do anything any more with Coyote. It is only left
around to support the deprecated Http11Connector.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 9:42 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java
luehe 2003/06/05 09:42:48
Modified:coyote/src/java/org/apache/coyote Request.java
http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java
Log:
Removed setSocket() method from org.apache.catalina.Request, since it
was never called in any of the classes implementing this interface.
For example, setSocket() was never called on
org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
method to always return null, which broke the CertificatesValve, which
relies on having access to the (SSL)Socket so that it can reinitiate a
handshake if necessary.
Instead, added setSocket() and getSocket() methods on
org.apache.coyote.Request:
- setSocket() is called as part of
org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
public void setSocket(Socket socket)
throws IOException {
this.socket = socket;
this.request.setSocket(socket); // NEW
}
- getSocket() is called as part of
org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
diff -u -r1.5 CoyoteRequest.java
--- CoyoteRequest.java 31 May 2003 15:00:25 - 1.5
+++ CoyoteRequest.java 5 Jun 2003 16:41:17 -
@@ -633,20 +633,7 @@
* an SSLSocket.
*/
public Socket getSocket() {
-return (socket);
-}
-
-/**
- * Set the Socket (if any) through which this Request was received.
- *
- * @param socket The socket through which this request was received
- */
-public void setSocket(Socket socket) {
-this.socket = socket;
-remoteHost = null;
-remoteAddr = null;
-remotePort = -1;
-localAddr = null;
+return coyoteRequest.getSocket();
}
Revision ChangesPath
1.21 +20 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Reques
t.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Request.java 23 Mar 2003 08:57:48 - 1.20
+++ Request.java 5 Jun 2003 16:42:48 - 1.21
@@ -62,6 +62,7 @@
import java.io.IOException;
import java.util.Hashtable;
+import java.net.Socket;
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.buf.MessageBytes;
@@ -137,6 +138,8 @@
private int remotePort;
+private Socket socket;
+
private MessageBytes schemeMB = new MessageBytes();
private MessageBytes methodMB = new MessageBytes();
@@ -304,6 +307,23 @@
this.remotePort = port;
}
+/**
+ * Sets the socket through which this request was received.
+ *
+ * @param socket The socket through which this request was received
+ */
+public void setSocket(Socket socket) {
+ this.socket = socket;
+}
+
+/**
+ * Gets the socket through which this request was received.
+ *
+ * @return The socket through which this request was received
+ */
+public Socket getSocket() {
+ return socket;
+}
// encoding/type
1.66 +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
cessor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Processor.java,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -r1.65 -r1.66
--- Http11Processor.java 13 May 2003 22:45:58 - 1.65
+++ Http11Processor.java 5 Jun 2003 16:42:48 - 1.66
@@ -517,6 +517,7 @@
public void setSocket(Socket socket)
throws IOException {
this.socket = socket;
+ this.request.setSocket(socket);
}
/**
1.27 +6 -5
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
tocol.java
Index: Http11Protocol.java
===
RCS file:
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 05, 2003 10:54 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java Bill Barker wrote: I'm very strongly -1 on this. The o.a.coyote.Request should not have a set/getSocket method for the simple reason that there is no reason that Coyote should be assumed to be tied to a socket transport. I plan to test the memory only protocol handler someday. The Netbeans folks should be happy about that (and the auto reload everything, of course). CertificatesValve doesn't do anything any more with Coyote. It is only left around to support the deprecated Http11Connector. Well, the connector won't work with TC 5 anyway, so ... I'm +1 for removing CertificatesValve from TC 5. Especially since it is tied to JSSE 1.0.x, so it will almost certainly break Tomcat running on a non-Sun 1.4 JVM. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 9:44 AM Subject: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java bobh2002/09/18 09:44:35 Modified:.gump.xml coyote/src/java/org/apache/coyote Request.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - This associates the socket with the Request. This is so the CertificatesValve.verify() can tell where (which socket) the Request is comeing from. Without this association, CertificatesValve.verify() returns with no SSL Handshake. - this change is in part based on feed back from; Vivek N. Yingxian Wang (JSSE), Craig M., Qingqing Ouyang I'm -1 on this, since having a socket in the Request makes no sense for Jk2. CertificatesValve is only for use with the deprecated HttpConnector. With Coyote, the SSL handling has moved to the connector (where it belonged in the first place). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 12:34 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java On Wed, 18 Sep 2002, Bill Barker wrote: Date: Wed, 18 Sep 2002 12:06:50 -0700 From: Bill Barker [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 9:44 AM Subject: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java bobh2002/09/18 09:44:35 Modified:.gump.xml coyote/src/java/org/apache/coyote Request.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - This associates the socket with the Request. This is so the CertificatesValve.verify() can tell where (which socket) the Request is comeing from. Without this association, CertificatesValve.verify() returns with no SSL Handshake. - this change is in part based on feed back from; Vivek N. Yingxian Wang (JSSE), Craig M., Qingqing Ouyang I'm -1 on this, since having a socket in the Request makes no sense for Jk2. CertificatesValve is only for use with the deprecated HttpConnector. With Coyote, the SSL handling has moved to the connector (where it belonged in the first place). The current Tomcat standalone implementation does not appear to meet the spec requirements for exposing a certificate chain, or for implementing CLIENT-CERT authentication. For the latter, the container needs to challenge the client to send a certificate if they didn't do so already. How do you propose to meet those requirements for Tomcat stand-alone without access to the underlying SSL socket? (For the connectors, you'll obviously need to provide an alternative solution to meet the spec requirements). The correct place to fix it is o.a.t.u.net.JSSESupport.getPeerCertificateChain (called from o.a.c.http11.Http11Processor.action). The code there was so heavily cribbed from CertificatesValve, that I should probably add you to the @author. :-) I'm strongly against reverting TC 4/5 back to only supporting JSSE (which would be the effect of requiring CertificatesValve). Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java
billbarker02/04/25 18:50:32 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java Log: Fix problem with soTimeout. The makes Coyote act like httpd with respect to soTimeout (which is what it was trying to do before, but only worked on HTTP/1.0 connectors). So the SoTimeout was overwritten ... You actually call setSoTimeout *a lot*. This is more flexible, since you can configure separately the connection timeout, but unless that call is free or almost free, this is not a good idea IMO. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
There are bugs that never die :)) Checked code and 3.2 is correct, 3.3 and coyote not, 4.0 original processor not checked, i think this is the third time i talk about the same, may be this is the third connector generation that jakarta-tomcat project does? ;) Larry we need to fix that ASAP, in 3.3 tree at least.. Just now 3.3 connector is defaulting to socket port, whena port is not present in the host header, we need to default to 80, and only use tyhe socket port in case of no Host Header.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
There are bugs that never die :)) Checked code and 3.2 is correct, 3.3 and coyote not, 4.0 original processor not checked, i think this is the third time i talk about the same, may be this is the third connector generation that jakarta-tomcat project does? ;) Larry we need to fix that ASAP, in 3.3 tree at least.. Just now 3.3 connector is defaulting to socket port, whena port is not present in the host header, we need to default to 80, and only use tyhe socket port in case of no Host Header.. Let me set that thing clearly. In HTTP/1.0, looking at the Host header is non standard. We can look at it if it is there (and I believe we do; if we don't it is very simple to change that), but in the end the HTTP/1.0 protocol is inefficient broken in many many ways, and it's not Tomcat's job to fix it. If NAT doesn't work with HTTP/1.0, then it is the protocol's fault. I don't know any client these days which wouldn't use HTTP/1.1 in its header anyway. In HTTP/1.1, we *only* look at the host header (so it works fine). I see a lot of noise from you about this trivial issue. Is there something I missed ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
I guess we're missing Nacho's commit that fixes the problem :-) Yes, he seemed to have a good idea about what was needed. It seems to be an itch for him - we're just making noise to encourage him to fix it :-) Since I was getting curious about what all this was about - :) - I went and looked at the code, and it looks as if the header is present, we're parsing it for HTTP/1.0 (looks good), but if no port is specified, in HTTP/1.1 we default to 80 (or 443), and in HTTP/1.0 we default to the socket port. It doesn't look very consistent to me ;-) Thanks, Remy, My language impedance is high at times ;), but it looks good now, Sorry for the noise, and thanks for the fix, Larry just now 3.3 has the very same problem i'll try to fix it.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
billbarker02/04/10 22:58:03
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Multiple Issues.
-- Degrade to the socket port on HTTP/1.0 requests with a Host header
but no port number.
-- Default to port 443 if an HTTP/1.1 request with no port header, but
we are configured to be Secure.
-- Remember the RemoteHost/RemoteAddr per-connection so that only one
lookup is necessary (the 3.3.x Adapter recycles these, so memory is good).
if (colonPos 0) {
-req.setServerPort(80);
+if( http11 ) {
+if(sslSupport == null) // not configured Secure
+req.setServerPort(80);
+else
+req.setServerPort(443); // if Secure, assume https
+} else {
+// Assume that non-HTTP/1.1 clients are broken
+req.setServerPort(socket.getLocalPort());
+}
req.serverName().setBytes( valueB, valueS, valueL);
} else {
req.serverName().setBytes( valueB, valueS, colonPos);
Yes, exactly what I wanted to do.
Thanks Bill.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: jueves 11 de abril de 2002 10:57 -- Degrade to the socket port on HTTP/1.0 requests with a Host header but no port number. if you are under a nat, dafaulting to the socket port maybe no correct, you could have tomcat in 8080, and the request would be redirected from a 80 port, so if a host header with no port is present the correct behavior should be to degrade to 80, without taking the socket port into consideration, as the client can actually see it as 80.. so we must obey the host header ever if present.. But may be i'm not understanding correctly what it's going here.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: jueves 11 de abril de 2002 10:57 -- Degrade to the socket port on HTTP/1.0 requests with a Host header but no port number. if you are under a nat, dafaulting to the socket port maybe no correct, you could have tomcat in 8080, and the request would be redirected from a 80 port, so if a host header with no port is present the correct behavior should be to degrade to 80, without taking the socket port into consideration, as the client can actually see it as 80.. so we must obey the host header ever if present.. That's what is done. In HTTP/1.0, there's no host header defined in the spec, so a client using and expecting it to work is non-compliant. In HTTP/1.1, we always follow the host header, and ignore what the socket says, according to the spec. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: jueves 11 de abril de 2002 12:12 That's what is done. In HTTP/1.0, there's no host header defined in the spec, so a client using and expecting it to work is non-compliant. Well, obeying the Host header ever, can be rfc compliant, because This specification reflects common usage of the protocol referred too as HTTP/1.0. This specification describes the features that seem to be consistently implemented in most HTTP/1.0 clients and servers. ( excerpt from RFC 1945 ), so this is not a real RFC, at least not one that must be obeyed in a compulsory way :)), at this moment, 3.3 does obeys a Host header present in a HTTP1.0 request, so having no need to implement that rfc completely ( it's more a compilation of commons practices than a must rfc), to be consistent to what 3.3 does right now seems to me a very good reason to obey the Host Header if present ever.. Just some thoughts, HTTP1.0 discussions are today more than a little useless and academic.., :))) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, April 11, 2002 7:41 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java On Thu, 11 Apr 2002, Remy Maucherat wrote: -- Degrade to the socket port on HTTP/1.0 requests with a Host header but no port number. if you are under a nat, dafaulting to the socket port maybe no correct, you could have tomcat in 8080, and the request would be redirected from a 80 port, so if a host header with no port is present the correct behavior should be to degrade to 80, without taking the socket port into consideration, as the client can actually see it as 80.. so we must obey the host header ever if present.. That's what is done. In HTTP/1.0, there's no host header defined in the spec, so a client using and expecting it to work is non-compliant. In HTTP/1.1, we always follow the host header, and ignore what the socket says, according to the spec. What we should do is respect the common practice ( the same as we do with the encoding - where almost all browsers are broken and we deal with that ). From what I've seen, HTTP/1.0 browsers do send the port if it's not 80 - and don't if the port is the default. If a Host is present we should use the port number the same as in HTTP/1.1. We do use the port number from the header, if the port is present. The current code handles HTTP/1.0 clients much the same way as Http10Interceptor does. Since the main HTTP/1.0 client that uses Tomcat is Watchdog, I don't really like enforcing the HTTP/1.1 behavior on HTTP/1.0 clients. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
costin 02/04/09 10:23:49 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: If host header is not set, use the local socket to set the local port and hostname. Remy - I'm not sure if this is correct, but I see no other way to pass this info ( I could add a callback - but this is needed in most calls ). If there is any particular reason to keep port and localhost unset I'll rollback and add the callback. ( this used to be in the 3.3-specific code, and is needed to construct redirects, etc ) +//The info from socket is usually acurate +// req.setServerPort(80); That's not good. If no host is specified with HTTP/1.1, we must default to the protocol default (as per the HTTP spec). The if HostMB == null implies HTTP/1.0 (with HTTP/1.1, the request processing would be mostly over without a Host header, with a 400 response). I've modified the patch to reflect this. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
On Tue, 9 Apr 2002, Remy Maucherat wrote: ( this used to be in the 3.3-specific code, and is needed to construct redirects, etc ) +//The info from socket is usually acurate +// req.setServerPort(80); That's not good. If no host is specified with HTTP/1.1, we must default to the protocol default (as per the HTTP spec). The information on the socket is allways accurate - the default isn't. I mean, if the request was received on port 8000, that's what the socket will 'tell' us, and it's allways correct. Same for 80, 443, etc. It's true, for HTTP/1.1 with the currect host you'll allways have the port if it is not the standard one. But if the Host header is correct, it'll allways be the same thing as the getPort on socket - if it's https on standard port, the port will be 443 as the default, etc. Even if the port in the host header isn't correct, we have to use it. Even if the socket isn't 80, we also have to default to that. That's bug 6668. The if HostMB == null implies HTTP/1.0 (with HTTP/1.1, the request processing would be mostly over without a Host header, with a 400 response). I've modified the patch to reflect this. So you don't fallback to HTTP/1.0 if a HTTP/1.0 request is received ? I thought that's required. Yes, HTTP/1.0 (with old style keepalives; that's new in Coyote HTTP/1.1) and HTTP/0.9 are supported. When using HTTP/1.0, the host header will be null, so we'll be using that code. Is there anything wrong ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
On Tue, 9 Apr 2002, Remy Maucherat wrote: port if it is not the standard one. But if the Host header is correct, it'll allways be the same thing as the getPort on socket - if it's https on standard port, the port will be 443 as the default, etc. Even if the port in the host header isn't correct, we have to use it. Even if the socket isn't 80, we also have to default to that. That's bug 6668. You're right. My mistake, if the Host header is present we must use the default port. That open another issue - the port must be what the 'original uri' specified - but what if you have a proxy that unencrypts SSL and forwards to the http port ? Probably that's fine since all Host headers I've seen for https include the port explicitely. I'll revert ( or did you do it already ? ) Yes, I modified the patch already. It's a good idea to set the socket port for HTTP/1.0, though (read below). Yes, HTTP/1.0 (with old style keepalives; that's new in Coyote HTTP/1.1) and HTTP/0.9 are supported. When using HTTP/1.0, the host header will be null, so we'll be using that code. Is there anything wrong ? Well, this part I think I'm right. If no Host header is specified - we should use the information from the socket, instead of defaulting to 80. Yes, that's what the fixed patch does. So I did it right, I think :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
costin 02/04/04 14:34:46 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Moved the parseHost method from coyote. That's another step in merging the connector code and sharing a single codebase. The Host: header is specific to http, other protocols may not need this operation. +1; this is HTTP/1.1 specific. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java InternalInputBuffer.java
I'd like it if this could make it into o.a.c.Processor as well. Since Costin has done a lot of work on this in 3.3, I'd like to make it settable (with a default of true), and if it is in Processor I don't have to resort to introspection. It's not a big deal, since the introspection tools are good. If you feel that this isn't going to stay around long, I can live with the introspection solution. No, I'd say it's very temporary, so I wouldn't worry about it at all. I'm experimenting :-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java InternalInputBuffer.java
I'd like it if this could make it into o.a.c.Processor as well. Since
Costin has done a lot of work on this in 3.3, I'd like to make it settable
(with a default of true), and if it is in Processor I don't have to resort
to introspection.
It's not a big deal, since the introspection tools are good. If you feel
that this isn't going to stay around long, I can live with the introspection
solution.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 09, 2002 11:05 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java InternalInputBuffer.java
remm02/03/09 11:05:35
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java InternalInputBuffer.java
Log:
- Port the tricks used by the old HTTP/1.1 connector to optimize
handling
of the US-ASCII parts of the HTTP header (method + protocol + header
names
+ URI in most cases).
- Note: The handling of the URI is probably not very satisfactory, but
until the
servlet container can handle a byte-based URL, there's no point in
being fancy.
Revision ChangesPath
1.6 +20 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
cessor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Processor.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Http11Processor.java 9 Mar 2002 05:20:03 - 1.5
+++ Http11Processor.java 9 Mar 2002 19:05:35 - 1.6
@@ -249,6 +249,26 @@
/**
+ * Get the value of the internationalized URI flag.
+ *
+ * @return the value of the internationalized URI flag
+ */
+public boolean isInternationalizedURIAllowed() {
+return inputBuffer.isInternationalizedURIAllowed();
+}
+
+
+/**
+ * Set the value of the internationalized URI flag.
+ *
+ * @param flag New value of the internationalized URI flag
+ */
+public void setInternationalizedURIAllowed(boolean flag) {
+inputBuffer.setInternationalizedURIAllowed(flag);
+}
+
+
+/**
* Process pipelined HTTP requests using the specified input and
output
* streams.
*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
