On Wed, Sep 4, 2013 at 11:03 AM, Jay McCarthy wrote:
> On Wed, Aug 28, 2013 at 3:30 PM, Greg Hendershott
> wrote:
>>
>> This looks great!!
>>
>> A couple suggestions:
>>
>> 1. Support for "Expect: 100-continue" request headers would be
>> helpful, and I think not too messy to add.
>>
>> The big u
On Wed, Aug 28, 2013 at 3:30 PM, Greg Hendershott wrote:
> This looks great!!
>
> A couple suggestions:
>
> 1. Support for "Expect: 100-continue" request headers would be
> helpful, and I think not too messy to add.
>
> The big use case I'm aware of is Amazon S3. If you make a PUT or POST
> reque
This looks great!!
A couple suggestions:
1. Support for "Expect: 100-continue" request headers would be
helpful, and I think not too messy to add.
The big use case I'm aware of is Amazon S3. If you make a PUT or POST
request, it might need to redirect you to another URI (outage,
balancing, whate
On Mon, Aug 26, 2013 at 6:46 AM, Sam Tobin-Hochstadt
wrote:
>
> On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy
> wrote:
>>
>> 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-p
On Fri, Aug 23, 2013 at 2:48 PM, Jay McCarthy
wrote:
>
> 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
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
6 matches
Mail list logo
