On May 21, 2008, at 9:05 PM, Ray Van Dolson wrote:
As I said, everything works fine this way. With mod_proxy in the mix
however:
1 TREO Sends OPTIONS request to Apache (Connection: Keep-Alive)
2 Apache Sends OPTIONS request to IIS (Connection: Close)
3 IIS Replies with 200 OK (Connection: Close)
4 Apache Sends 200 OK back to Treo (Connection: Close)
5 Apache Sends SSLv3 Close Notify to Treo
6 Apache Sends FIN,ACK to Treo
7 TREO Sends POST /Microsoft-Server-ActiveSync... (Connection:
Keep-Alive)
8 Apache Sends ACK to Treo
9 Apache Sends Dup ACK to Treo
10 Apache Sends Dup ACK to Treo
Timeout...
I attempted to backport the patches mentioned here:
http://svn.apache.org/viewvc?view=rev&revision=657440
In the hopes it might address this, but I'm still seeing the
connection
prematurely closed around #5, #6 above. I *believe* this is the cause
of my issue but am not positive. The Treo continues to try and use an
existing connection that no longer exists, and Apache keeps sending
Connection: close headers.
I don't see how this is a bug. Why does the TREO not
close the socket and reopen another? How is it "premature"?
The server can decide to say "That's enough" at any time and
the client must honor that. Instead, it looks like the
TREO is seeing 'Connection: close' and ignoring it and
considering the connection persistent.
This is all made trickier by SSL being in used end to end and
Wireshark
not consistently decrypting packets :)
Any thoughts or advice? I feel if I can just get Apache to quit
forcing the Connection: close headers in there this would work.
Ray