<div dir="ltr">On Wed, Aug 28, 2013 at 3:30 PM, Greg Hendershott <span dir="ltr"><<a href="mailto:greghendershott@gmail.com" target="_blank">greghendershott@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks great!!<br> <br> A couple suggestions:<br> <br> 1. Support for "Expect: 100-continue" request headers would be<br> helpful, and I think not too messy to add.<br> <br> The big use case I'm aware of is Amazon S3. If you make a PUT or POST<br> request, it might need to redirect you to another URI (outage,<br> balancing, whatever reason). Expecting and handling 100-continue lets<br> you avoid transmitting potentially large amount of data that would be<br> discarded, and you have to send it all over again in the request to<br> the redirect URI. For (say) a 1 GB upload to S3, this matters.<br> Although I don't know for sure if other upload-ish web APIs offer<br> same, I'd guess some do as this is the use case for 100-continue<br> generally.<br> <br> How I implemented this in my HTTP package was to have a<br> `start-request` function that sends the request line and headers,<br> peeks the response status line, then returns a `boolean?` whether the<br> PUT/POST/PATCH/whatever data should be transmitted. [1]<br> <br> I think your `http-conn-send!` could do similar?<br></blockquote><div><br></div><div>Do you think it is appropriate to expect the http-client user to put in the "Expect: 100-continue" or better to always send it if there is a data component?</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2. Support for "Content-Encoding" response headers would also be helpful.<br> <br> Using the same make-pipe approach as you're doing with chunked<br> transfer encoding. [2] Maybe this is mission creep: For HTTP 1.1. you<br> _must_ support Transfer-Encoding: chunked, whereas Content-Encoding is<br> just optional. However it's a good option; using compression can<br> really help out on time as well as bandwidth charges.<br></blockquote><div><br></div><div>I just pushed support for this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> IIRC those were the two main things that motivated me to make my HTTP<br> package at all, to support e.g. my AWS package. If http-client added<br> them, I might not need my package anymore. (OK, it might take me<br> awhile to phase it out until I'm ready to de-support older versions of<br> Racket, but, I and others wouldn't need it for new projects.)<br> <br> <br> [1]: <a href="https://github.com/greghendershott/http/blob/master/http/request.rkt#L142-L189" target="_blank">https://github.com/greghendershott/http/blob/master/http/request.rkt#L142-L189</a><br> <br> [2]: By the way, do you want to pass some `limit` optional arg in the<br> various uses of `make-pipe`? Otherwise IIUC this will suck everything<br> into RAM, which might not be so great with very large request or<br> response entities.<br></blockquote><div><br></div><div>Matthew changed this a few days ago.</div><div><br></div><div>Jay</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><br> <br> On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote:<br> </div><div><div class="h5">> Based on a request back in early July to remove the restrictions that<br> > net/url puts on HTTP communication (vis a vis URL encoding), I have<br> > just pushed a new HTTP client as net/http-client.<br> ><br> > The push also changes net/url to use net/http-client so that we just<br> > have 1 HTTP request producer, rather than 3.<br> ><br> > It passes all of the net/* tests, but these don't use features like<br> > proxying, HTTP/1.1, etc. I'm slightly nervous that it doesn't do those<br> > correct, but not super nervous, because I just cut-and-pasted the<br> > code.<br> ><br> > The main approach of the library is best explained by this contract:<br> ><br> > [http-sendrecv<br> > (->* ((or/c bytes? string?) (or/c bytes? string?))<br> > (#:ssl? (or/c boolean? ssl-client-context? symbol?)<br> > #:port (between/c 1 65535)<br> > #:method (or/c bytes? string? symbol?)<br> > #:headers (listof (or/c bytes? string?))<br> > #:data (or/c false/c bytes? string?))<br> > (values bytes? (listof bytes?) input-port?))]<br> ><br> > Compared to net/url,<br> > - It supports bytes and strings everywhere<br> > - It supports data on every method and not just POST<br> > - It always returns the status line, headers, and content (as a port)<br> ><br> > I feel that the only thing it could do better is support two more<br> > options for #:data:<br> > - A input-port? to read from and copy to the HTTP connection<br> > - A (-> output-port? void) function to call with the HTTP connection's<br> > output port to stream the data<br> ><br> > But I'd like a second opinion before adding them.<br> ><br> > Jay<br> ><br> > --<br> > Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br> > Assistant Professor / Brigham Young University<br> > <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br> ><br> > "The glory of God is Intelligence" - D&C 93<br> </div></div>> _________________________<br> > Racket Developers list:<br> > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> </blockquote></div><br><br clear="all"><div><br></div>-- <br>Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br> <br>"The glory of God is Intelligence" - D&C 93 </div></div>