Arturo 'Buanzo' Busleiman wrote: > Nick Kew wrote: >>> It's your question that I find hard to decipher. > > Yes, I'm sorry. Let me try and explain. > > For example, If I read this request with my connection input filter (which I > was able to do): > > =- cut here -= > POST /HTTP_OPENPGP_DECRYPT > Host: localhost
FWIW, this isn't a valid HTTP request. The bare minimum was POST /HTTP_OPENPGP_DECRYPT HTTP/1.1 (the last bit was not optional.) Out of curiosity, is this how current browsers introduced PGP request signing support? Split headers? To remain compatible with other servers, it was trivial to simply provide a signature header. One issue though, you can't prevent minor bits from being flipped on the way thorough, so that would be a problem when passing through proxies. Second issue, you can't trust the Host: header as it wasn't crypted (or signed). Worst, you expected Connection: keep-alive to behave (it's actually redundant for HTTP/1.1) but then failed to pass Content-Length in an non-crypted form. The server would have ENOCLUE where the POST ended. That's likely to be part of your problem. This is a bad engineering design, as TOKiley points out. You really should look at Connection-Upgrade semantics from RFC 2816 for how this should have been handled. Is there an RFC on this (even draft)? Perhaps you misread it; if not, something is horribly broken in the review process under our AD :) Bill
