Based on a request back in early July to remove the restrictions that net/url puts on HTTP communication (vis a vis URL encoding), I have just pushed a new HTTP client as net/http-client.
The push also changes net/url to use net/http-client so that we just have 1 HTTP request producer, rather than 3. It passes all of the net/* tests, but these don't use features like proxying, HTTP/1.1, etc. I'm slightly nervous that it doesn't do those correct, but not super nervous, because I just cut-and-pasted the code. The main approach of the library is best explained by this contract: [http-sendrecv (->* ((or/c bytes? string?) (or/c bytes? string?)) (#:ssl? (or/c boolean? ssl-client-context? symbol?) #:port (between/c 1 65535) #:method (or/c bytes? string? symbol?) #:headers (listof (or/c bytes? string?)) #:data (or/c false/c bytes? string?)) (values bytes? (listof bytes?) input-port?))] Compared to net/url, - It supports bytes and strings everywhere - It supports data on every method and not just POST - It always returns the status line, headers, and content (as a port) I feel that the only thing it could do better is support two more options for #:data: - A input-port? to read from and copy to the HTTP connection - A (-> output-port? void) function to call with the HTTP connection's output port to stream the data But I'd like a second opinion before adding them. Jay -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev