Bug 107229
Summary: | Apache 2.x/1.x return extra chars in 404 and 401 requests (others?). | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Cove Schneider <cove> |
Component: | httpd | Assignee: | Joe Orton <jorton> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | cove |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
URL: | https://www.wildpackets.com/brokenlink | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-10-29 18:23:11 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Cove Schneider
2003-10-15 23:48:06 UTC
The telnet output is a correct HTTP/1.1 response including the chunked encoding. What bug are you seeing in a real browser, in what circumstances, in what configuration? Ok. I didn't know this was chunked encoding. The problem that I'm having is with using Apple's Safari v1.0 (85.5) browser accessing SquirrelMail 1.4.2. For some reason when using SSL the login hangs indefinably. Since the connection is over SSL, I'm not able to determine what's going on. I tried using ssldump, but it doesn't display the http session for some reason. Any suggestions appreciated. Have you confirmed that it only fails if using Safari and SSL? Other browsers with SSL work, likewise Safari with non-SSL? You can get ssldump to display application (HTTP) traffic, with the -d flag, if you also point it at the private key for the SSL server using -k - the man page explains the options. I've determined that only Safari is effected. Netscape works and so does IE. Here's what I get with ssldump -d (-A doesn't help either): New TCP connection #2: wrks-10-4-3-220.dhcp.wildpackets.com(53853) <-> rst.wildpackets.com(443) 2 1 0.0012 (0.0012) C>S SSLv2 compatible client hello Version 3.1 cipher suites TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xff83 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_DES_CBC_SHA Unknown value 0xff82 TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL_RSA_WITH_RC2_CBC_MD5 TLS_RSA_WITH_NULL_MD5 SSL2_CK_RC4 SSL2_CK_RC4_EXPORT40 SSL2_CK_RC2 SSL2_CK_RC2_EXPORT40 SSL2_CK_DES SSL2_CK_3DES 2 2 0.0017 (0.0005) S>C Handshake ServerHello Version 3.1 session_id[32]= 94 c3 c1 47 23 92 7f db 15 6a 25 1a ee 2f 4a 25 fc b8 f7 ff e1 80 8a bf 21 4e ea 2a 09 92 e7 13 cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 2 3 0.0017 (0.0000) S>C Handshake Certificate 2 4 0.0017 (0.0000) S>C Handshake ServerHelloDone 2 5 0.0065 (0.0047) C>S Handshake ClientKeyExchange 2 6 0.0414 (0.0348) C>S ChangeCipherSpec 2 7 0.0414 (0.0000) C>S Handshake 2 8 0.0418 (0.0003) S>C ChangeCipherSpec 2 9 0.0418 (0.0000) S>C Handshake 2 10 0.0433 (0.0015) C>S application_data 2 11 0.1378 (0.0944) S>C application_data At this point it hangs. I'm not sure why -d doesn't dump the ASCII data, from the best I can determine ssldump uses ctype functions to determin weather data is printable or not. This is partly what lead me to believe that the Apache server was returning questionable data, albeit it could just as well be an oversight in ssldump. Latest version of Safari 1.1 (v100) resolves this issue. |