Re: [racket] net/http-client

2013-09-24 Thread Evan Donahue
Valid. I guess I shouldn't pin too much faith on something that introduces itself in the comments as a "wanna be library." On Tue, Sep 24, 2013 at 12:13 PM, Jay McCarthy wrote: > On Tue, Sep 24, 2013 at 12:31 PM, Evan Donahue wrote: > > Hmm, I'm no expert on http cookies, but here are the stick

Re: [racket] net/http-client

2013-09-24 Thread Jay McCarthy
On Tue, Sep 24, 2013 at 12:31 PM, Evan Donahue wrote: > Hmm, I'm no expert on http cookies, but here are the sticking points (or > possibly misinterpretations of the spec and/or the library) that have been > holding me up (referencing rfc2965): > > 1) the print-cookie function generates path, doma

Re: [racket] net/http-client

2013-09-24 Thread Evan Donahue
Hmm, I'm no expert on http cookies, but here are the sticking points (or possibly misinterpretations of the spec and/or the library) that have been holding me up (referencing rfc2965): 1) the print-cookie function generates path, domain, comment, etc fields that don't belong in a Cookie header, so

Re: [racket] net/http-client

2013-09-24 Thread Jay McCarthy
I believe the net/cookie was intended to be used for both client and server. For instance, print-cookie turns a cookie structure into a string, which is a header that can be used on either side. I think the only thing that would be needed as far as structure accessors would be a way to find the coo

Re: [racket] net/http-client

2013-09-23 Thread Evan Donahue
As long as people are discussing http client libraries, I've been wondering what the status of net/cookie is. It seems that it's geared towards server-side cookie management (and I don't see an obvious way to generate Cookie: headers from net/cookie structs since none of the accessors are exported)

Re: [racket] net/http-client

2013-09-19 Thread Erik Pearson
Just finishing up a two day wrestling match with net/url, couchdb, and assorted other incomplete libraries ... I have some fresh insight. First, the new http client library will be very welcome! A quick review of the existing code relieves me of most of my worries about net/url, which is a bit of

Re: [racket] net/http-client

2013-09-17 Thread Erik Pearson
I was crafting a response, but I think Norman here represents what I was expressing, with some comments below ... On Tue, Sep 17, 2013 at 7:34 AM, Norman Gray wrote: > > Greetings. > > On 2013 Sep 17, at 14:51, Jay McCarthy wrote: > > > I think it's an obvious request, but a character flaw of m

Re: [racket] net/http-client

2013-09-17 Thread Greg Hendershott
> For these reasons, I think http-client should just return the list of > bytes. I think it would be nice to have another function that parses > that so clients could optionally call it if it is important. That can > be part of http-client. I agree. Although I usually find it much more convenient/

Re: [racket] net/http-client

2013-09-17 Thread Norman Gray
Greetings. On 2013 Sep 17, at 14:51, Jay McCarthy wrote: > I think it's an obvious request, but a character flaw of mine is not > doing things unless they can be done really good. In this case, I see > a hash table as a "parse" of the headers. It's not obvious to me how > to parse them. For exa

Re: [racket] net/http-client

2013-09-17 Thread Robby Findler
A new kind of dict seems like it would be able to deal with much of this. For example, you could have a 'get' operation that would deal with the multiple headers situation in a way that is likely to be what was intended (whether that's an error or a 'get the last one' or some other operation) and a

Re: [racket] net/http-client

2013-09-17 Thread Jay McCarthy
I think it's an obvious request, but a character flaw of mine is not doing things unless they can be done really good. In this case, I see a hash table as a "parse" of the headers. It's not obvious to me how to parse them. For example... - The same header can appear many times, so (Key -> Value) i

Re: [racket] net/http-client

2013-09-16 Thread Jay McCarthy
My intention is for these functions to be friendlier and easier to find (because they have HTTP in the name of the functions and the section), but if I am wrong, then I don't want to put in a note in the net/url manual that says "These are bad old legacy stuff." Jay On Mon, Sep 16, 2013 at 10:35

Re: [racket] net/http-client

2013-09-16 Thread Michael Wilber
Interesting. Does this replace get-pure-port and friends? If not, maybe we should include some wording in the docs for new users: "These functions are for those who need low-level control over their HTTP requests. For a friendlier and more conventional HTTP interface, see ..." Jay McCarthy writes

Re: [racket] net/http-client

2013-09-12 Thread Jay McCarthy
It exists, but it is only in the latest version. https://github.com/plt/racket/blob/master/racket/collects/net/http-client.rkt If you look at the snapshots, you can see the docs: http://www.cs.utah.edu/plt/snapshots/current/doc/net/http-client.html?q=net/http-client Jay On Thu, Sep 12, 2013 a