Error in HTTP 4.004 + CouchDB?

Hello (i sent this message to the mail of author, specified at hackage, but it returned to me, so i decided to resend it here) I found strange thing during work with latest versions of CouchDB & HTTP module on my Mac OS X 10.4. The problem is, that when i send document to the couchdb server, it name was cut to the 2 characters. After some investigation i found, that this is problem in combination of the CouchDB + HTTP usage. CouchDB module fills out the Request structure, and specify scheme & authority fields. This lead that i see (in network dumps) following data: PUT http://127.0.0.1:5984/test1/Users_ott_tmp_1_tst HTTP/1.1 Content-Type: ... ... Host: 127.0.0.1:5984 ... instead of proper PUT /test1/Users_ott_tmp_1_tst HTTP/1.1 I can eliminate this by explicitly setting of the scheme & authority into empty values, but this lead to improper creation of the Host header in request: PUT /test1/Users_ott_tmp_1_tst HTTP/1.1 Content-Type: ... ... Host: ... I tried to fix this problem myself, but I'm novice in the industrial Haskell programming ;-) P.S. this code from (CouchDB/HTTP.hs) will restore proper behaviour of the code, but break Host header makeURL path query = CouchMonad $ \conn -> do return ( (ccURI conn) { uriPath = '/':path , uriQuery = if null query then "" else '?':(urlEncodeVars query) , uriScheme = "" , uriAuthority = Nothing } ,conn ) -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/

Thanks Alex, contacting the maintainer of a package rather than author is probably the best course of action in general. They may both be out of date, but the former maybe less so. :) As verified offline, you issue this request via sendHTTP when experiencing this misbehavior. A couple of suggestions on what to do: * Use Network.Browser instead and send it via (browse $ request req), which will normalize the path and Host: headers as you expect for (non-proxy) use. * pull down the latest bits from the repository and normalize your request prior to calling sendHTTP by using (Network.HTTP.Base.normalizeRequest False{-no proxy-} req) (we're in a tight spot wrt. backwards compatibility for sendHTTP, so having it perform this normalization step by default would break code that now interacts with proxies via sendHTTP.) The repository version also has support for custom request verbs, which might be of interest&use to some. Let me know how it goes -- git repository URL available via http://projects.haskell.org/http/ hth --sigbjorn On 1/22/2009 11:32, Alex Ott wrote:
Hello
(i sent this message to the mail of author, specified at hackage, but it returned to me, so i decided to resend it here)
I found strange thing during work with latest versions of CouchDB & HTTP module on my Mac OS X 10.4. The problem is, that when i send document to the couchdb server, it name was cut to the 2 characters.
After some investigation i found, that this is problem in combination of the CouchDB + HTTP usage. CouchDB module fills out the Request structure, and specify scheme & authority fields. This lead that i see (in network dumps) following data:
....
I tried to fix this problem myself, but I'm novice in the industrial Haskell programming ;-)
P.S. this code from (CouchDB/HTTP.hs) will restore proper behaviour of the code, but break Host header
makeURL path query = CouchMonad $ \conn -> do return ( (ccURI conn) { uriPath = '/':path , uriQuery = if null query then "" else '?':(urlEncodeVars query) , uriScheme = "" , uriAuthority = Nothing } ,conn )

* Alex Ott
PUT http://127.0.0.1:5984/test1/Users_ott_tmp_1_tst HTTP/1.1 Content-Type: ... ... Host: 127.0.0.1:5984 ...
Note that this is a valid HTTP request, according to my reading of RFC2616. -- mithrandi, i Ainil en-Balandor, a faer Ambar

On Sat, 24 Jan 2009 14:18:24 Tristan Seligmann wrote:
* Alex Ott
[2009-01-22 20:32:26 +0100]: PUT http://127.0.0.1:5984/test1/Users_ott_tmp_1_tst HTTP/1.1 Content-Type: ... ... Host: 127.0.0.1:5984 ...
Note that this is a valid HTTP request, according to my reading of RFC2616.
Depends what you mean by valid. Yes it's a valid request to receive, no an implementation is not compliant with RFC2616 if it issues a request like this to an origin server. Have a look at section 5.1.2. An implementation is REQUIRED to issue requests like this to proxies, an implementation MUST handle receiving requests like this, an implementation MUST use the abs_path form in requests to origin servers and gateways, ie PUT /test1/Users_ott_tmp_1_tst HTTP/1.1 Host: 127.0.0.1:5984 Dan
participants (4)
-
Alex Ott
-
Daniel McAllansmith
-
Sigbjorn Finne
-
Tristan Seligmann