Possible bug in using 'recv-key' facility via a HTTP proxy

[Steven Murdoch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 20:19 20/04/01 +0200, you wrote:
>On Sat, 14 Apr 2001, Steven Murdoch wrote:
>
>> consist of no more than a 30 minute lecture so I cannot guarantee this
>> is correct however I think the FIN is sent from the 'shutdown()'
>> system call at line 132 of version gnupg-1.0.4 (function
>
>This is correct; it indicates an EOF on the server side.  IIRC, a
>long time ago we had a some problems with some proxies but we
>eventaully made it work and that is what we have now.

When you say this is correct do you mean this is what's happening, or
that this is what should be happening? I was under the (possibly
erroneous) impression that the FIN packet indicated that one side
wished to close the connection, however GnuPG seems to send it after
the HTTP request and before the server sends the key back. In my case
after GnuPG sends the FIN packet the proxy server replies with a FIN
and the connection is torn down before the key is received.

When the shutdown call is taken out, the proxy server sends the key to
GnuPG then the server sends the FIN packet and GnuPG replies with
another FIN.

The difference here is who sends the first FIN packet. Currently GnuPG
sends it when it no longer has any data to send, but it still wants
some data and the connection should be maintained. With my
modification the server sends the FIN packet first, when it has no
more data to send and the connection can be closed.

Which is the correct option depends on the semantics of the FIN
packet. To put it simply, does it mean "I'm not going to send more
data" or "I'm not going to send anything, nor do I want anything back,
so please close the connection"?

>> http_wait_response()). When I took this out the FIN was not sent
>> however neither were the \r and \n sent to hd->fp_write (line 113,
>> http_start_data()), it was as if the buffer was never flushed, but I
>
>Hmmm, this is strange.  I double checked that even on a close we do
>a flush which in turn will write out all buffered stuff.  And there
>is even an iobuf_flush() right before the close.

I noticed this too and was surprised when the buffered characters were
not sent. I could be wrong though so feel free to check.

In case I didn't make it clear in my last mail, I should reiterate
that the patch I sent is not the correct solution to the
problem. There are still several things going on that I don't
understand so the patch was to illustrate these.

Thank you,

Steven Murdoch.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE64yrNy7aeQyigOIYRArZwAJ9JTEuLNo1G9/MgsHvDris/7ye1qACgmKOq
9Q/9pRCo3jk6jgnLeq7Sd1A=
=fedI
-----END PGP SIGNATURE-----

-- 
email: sjmurdoch at bigfoot.com
web: http://www.dcs.gla.ac.uk/~murdocsj/
PGP/GnuPG keys: http://www.bigfoot.com/~sjmurdoch/keys.html