[
https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thach Tran updated TS-2306:
---------------------------
Description:
Setup:
ATS in reverse proxy mode and Apache server in the backend to serve some very
large test files (~10GB). Backend Apache server listens on both 80 for plain
HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 8080
and 8081):
map http://localhost:8080/ http://localhost/
map http://localhost:8081/ https://localhost/
What I am seeing is request for http://localhost:8081/files/testfile10g.bin
will hang very quickly without getting much data back while request for
http://localhost:8080/files/testfile10g.bin will continue to download just fine
until it's finished. I've tried with other smaller files (~200MB, ~1MB) and it
seems to work fine.
I've disabled the caching (proxy.config.http.cache.http=0) in case it has
something to do with that.
I'm wondering if this is similar to TS-2211 but in reverse direction (client is
non-SSL while origin connection is SSL). I've tested with trunk which includes
a fix for TS-2211 but still be able to reproduce this.
In my test setup both ATS and Apache are running on the same Linux Mint 13 box
(which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1.
Any help would be much appreciated.
was:
Setup:
ATS in reverse proxy mode and Apache server in the backend to serve some very
large test files (~10GB). Backend Apache server listens on both 80 for plain
HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 8080
and 8081):
map http://localhost:8080/ http://localhost/
map http://localhost:8081/ https://localhost/
What I am seeing is request for https://localhost:8080/files/testfile10g.bin
will hang very quickly without getting much data back while request for
http://localhost:8081/files/testfile10g.bin will continue to download just fine
until it's finished. I've tried with other smaller files (~200MB, ~1MB) and it
seems to work fine.
I've disabled the caching (proxy.config.http.cache.http=0) in case it has
something to do with that.
I'm wondering if this is similar to TS-2211 but in reverse direction (client is
non-SSL while origin connection is SSL). I've tested with trunk which includes
a fix for TS-2211 but still be able to reproduce this.
In my test setup both ATS and Apache are running on the same Linux Mint 13 box
(which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1.
Any help would be much appreciated.
> Client connection hang while downloading big file from origin server over SSL
> connection
> ----------------------------------------------------------------------------------------
>
> Key: TS-2306
> URL: https://issues.apache.org/jira/browse/TS-2306
> Project: Traffic Server
> Issue Type: Bug
> Components: Network, SSL
> Reporter: Thach Tran
> Fix For: 4.2.0
>
>
> Setup:
> ATS in reverse proxy mode and Apache server in the backend to serve some very
> large test files (~10GB). Backend Apache server listens on both 80 for plain
> HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of
> 8080 and 8081):
> map http://localhost:8080/ http://localhost/
> map http://localhost:8081/ https://localhost/
> What I am seeing is request for http://localhost:8081/files/testfile10g.bin
> will hang very quickly without getting much data back while request for
> http://localhost:8080/files/testfile10g.bin will continue to download just
> fine until it's finished. I've tried with other smaller files (~200MB, ~1MB)
> and it seems to work fine.
> I've disabled the caching (proxy.config.http.cache.http=0) in case it has
> something to do with that.
> I'm wondering if this is similar to TS-2211 but in reverse direction (client
> is non-SSL while origin connection is SSL). I've tested with trunk which
> includes a fix for TS-2211 but still be able to reproduce this.
> In my test setup both ATS and Apache are running on the same Linux Mint 13
> box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1.
> Any help would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
