Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java
[EMAIL PROTECTED] wrote: billbarker2003/07/13 14:53:07 Modified:http11/src/java/org/apache/coyote/http11 Tag: coyote_10 Http11Processor.java Log: Porting patch. Ok, so TC 4.1.25 is dead ;-) I'm glad I didn't upload the binaries yet :) 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/http11Http11Processor.java
[EMAIL PROTECTED] wrote:
billbarker2003/07/04 18:39:42
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
Reverting previous patch.
I included the code that httpd actually uses, in case somebody else likes the idea.
However, I left it commented out, so that the only effect it has to to add a few bytes to the .class file.
If nobody else likes the idea, I'll clean it out later.
+/**
+ * Determine if we must drop the connection because of the HTTP status
+ * code. Use the same list of codes as Apache/httpd.
+ */
+protected boolean statusDropsConnection(int status) {
+return status == 400 /* SC_BAD_REQUEST */ ||
+ status == 408 /* SC_REQUEST_TIMEOUT */ ||
+ status == 411 /* SC_LENGTH_REQUIRED */ ||
+ status == 413 /* SC_REQUEST_ENTITY_TOO_LARGE */ ||
+ status == 414 /* SC_REQUEST_URI_TOO_LARGE */ ||
+ status == 500 /* SC_INTERNAL_SERVER_ERROR */ ||
+ status == 503 /* SC_SERVICE_UNAVAILABLE */ ||
+ status == 501 /* SC_NOT_IMPLEMENTED */;
+}
I like the list contents. Very sensible (silly me for doubting the HTTPd
folks ;-) ).
+1 for uncommenting the patch.
BTW, I don't know if the exception field is correctly set on the
Response object. If it is set, it's also a good reason to disconnect (IMO).
I'm off for the WE :)
For info, I plan to tag 4.1.25 early next week.
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/http11Http11Processor.java Http11Protocol.java
[EMAIL PROTECTED] wrote:
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:
Ouch, that's one nasty hack.
-1, please revert it.
There are callbacks to the processor to evaluate the SSL related
attributes. If something is broken, this should be fixed, but using that
pattern. I believe get/setSocket are useless, and the calls should be
entierely removed.
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/http11Http11Processor.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 ... 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/http11Http11Processor.java
[EMAIL PROTECTED] wrote: remm2002/12/19 01:19:06 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: - Same, but without the tabs ;-) Oups, sorry. -- 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/http11Http11Processor.java
Bill Barker wrote: - 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). I agree. I forgot this was done through a notification, and 99% of the code was already there. Thanks for adding the clientauth support and removing the need for hacks. I will revert the changes to Http11Processor and Request. 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/http11Http11Processor.java
Bob Herrmann wrote: On Wed, 2002-09-18 at 13:58, Remy Maucherat wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: 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 -1 (ie, revert this). The socket should already have been associated with the request, but as a note. It is available, and accessible. Ok, I checked it, and the socket os not currently associated with the request (I thought it was). OTOH, you shouldn't add a field for socket in the request (native webservers don't have the notion of a Java socket). Instead, use one of the notes. Ok, - change Http11Processor to use a note - change Request.java to it's original form - change the CertificatesValve.verify() Does that sound about right? For me: yes. Cheers, -bob Remy -- 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/http11Http11Processor.java
[EMAIL PROTECTED] wrote: 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 -1 (ie, revert this). The socket should already have been associated with the request, but as a note. It is available, and accessible. Thanks, 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/http11Http11Processor.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: 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 -1 (ie, revert this). The socket should already have been associated with the request, but as a note. It is available, and accessible. Ok, I checked it, and the socket os not currently associated with the request (I thought it was). OTOH, you shouldn't add a field for socket in the request (native webservers don't have the notion of a Java socket). Instead, use one of the notes. 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/http11Http11Processor.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). Craig -- 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/http11Http11Processor.java
On Fri, 12 Apr 2002, Remy Maucherat wrote: 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 The Host header is not specified in the standard - it's what we would call a 'standard extension' :-) There are few extensions to the HTTP/1.0 that are in very common use - in the sense that all browsers and most clients support them, and Host is the best example. Some of those extensions found their way into HTTP/1.1 spec. AFAIK Host: allways worked this way ( at least in the last 5 years ). 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). No, it's just a bug in our code ( both 3.3 and coyote ). If a Host header is present, it should be interpreted exaclty as in HTTP/1.1. I see a lot of noise from you about this trivial issue. Is there something I missed ? I guess we're missing Nacho's commit that fixes the problem :-) It seems to be an itch for him - we're just making noise to encourage him to fix it :-) Costin -- 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/http11Http11Processor.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. Costin -- 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/http11Http11Processor.java
On Thu, 11 Apr 2002, Bill Barker wrote: 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. IE/Netscape/Mozilla/Opera ( set in HTTP/1.0 mode ) are sending a Host: header. Some don't include the port if the port is 80, but include it if it's not. ( at least that's what I remember ) I would rather enforce what the browsers are doing, not watchdog :-) I think Nacho has a valid point - using the port from socket ( when a Host header is present ) works fine unless a redirection is done by some hardware/ipchain/tcpmon/etc. This redirection is not that uncommon ( especially if you don't want to run tomcat directly on 80 for some reasons ) If we don't have a Host header - socket is the only choice and we should use it. But if a Host: is present, I would rather fix watchdog to do what the browsers are doing. ( of course, that would require someone to actually verify what are the browsers sending - and I won't do it, Character-Set hunting was more then enough for me... ) Costin -- 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/http11Http11Processor.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. 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. Costin -- 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/http11Http11Processor.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, 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. Costin -- 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/http11Http11Processor.java
On Tue, 9 Apr 2002, Remy Maucherat wrote: Yes, that's what the fixed patch does. So I did it right, I think :) Thanks. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
