[go-nuts] Re: best practices of client middleware

[Eyal Posener]

Very Nice stuff - shame he didn't merge it.
But I see that you changes the request in the RoundTrip function, which is 
claimed as forbidden in the docs.
Again, I don't understand why the docs forbid it...


On Wednesday, March 7, 2018 at 1:52:55 AM UTC+2, Sangjin Lee wrote:
>
> I offered a PR on alice (which is a middleware library for the handlers) 
> that does that. It's essentially an application of the same pattern. We're 
> getting a lot of mileage for this.
>
> https://github.com/justinas/alice/pull/40
>
> On Tuesday, March 6, 2018 at 6:41:53 AM UTC-8, Eyal Posener wrote:
>>
>> Good stuff,
>> So I see that this library wraps the http.Client and doesn't use the 
>> roundtripper.
>> Pretty elegant!
>>
>> I still have two questions about the standard library:
>>
>>- Didn't understand yet why it is not allowed to add headers in the 
>>roundtripper.
>>- Is this a bit strange that the standard library provides a 
>>beautiful way to have server middleware, but no way to have client 
>>middlewares?
>>
>> Cheers,
>> Eyal
>>
>> On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote:
>>>
>>> As far as I am aware, there is very little information about best 
>>> practices regarding client side middlewares. 
>>>
>>> I though that having such support is neat idea and I have implemented 
>>> something (that I use for some time now, though still in beta) that you 
>>> might find useful for your use case. I have written small library that 
>>> describes client middleware protocol , 
>>> some useful middlewares  
>>> and HTTP client  that's using these 
>>> libraries. 
>>>
>>> This might solve your problem directly (writing new middleware is 
>>> trivial), but it might introduce dependency that you don't want, so I hope 
>>> this will provide inspiration on how you would do something similar 
>>> yourself. 
>>>
>>> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:

 Hi

 I want to implement a client middleware - for example: sign the request 
 body and add the signature as an HTTP header.
 I thought that the best way to do it is to implement a RoundTripper 
 interface  which up on 
 request, calculate the signature, adds the header, and invoke a "next" 
 ToundTripper.

 This could be a very generic implementation, which i can inject to any 
 client that uses the standard library http.Client.

 However, I found the following in the doc:

 // RoundTrip should not modify the request, except for
 // consuming and closing the Request's Body. RoundTrip may
 // read fields of the request in a separate goroutine. Callers
 // should not mutate the request until the Response's Body has
 // been closed.


 Is there a standard way to do it?

 Thanks,
 Eyal

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: best practices of client middleware

[Sangjin Lee]

I offered a PR on alice (which is a middleware library for the handlers) 
that does that. It's essentially an application of the same pattern. We're 
getting a lot of mileage for this.

https://github.com/justinas/alice/pull/40

On Tuesday, March 6, 2018 at 6:41:53 AM UTC-8, Eyal Posener wrote:
>
> Good stuff,
> So I see that this library wraps the http.Client and doesn't use the 
> roundtripper.
> Pretty elegant!
>
> I still have two questions about the standard library:
>
>- Didn't understand yet why it is not allowed to add headers in the 
>roundtripper.
>- Is this a bit strange that the standard library provides a beautiful 
>way to have server middleware, but no way to have client middlewares?
>
> Cheers,
> Eyal
>
> On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote:
>>
>> As far as I am aware, there is very little information about best 
>> practices regarding client side middlewares. 
>>
>> I though that having such support is neat idea and I have implemented 
>> something (that I use for some time now, though still in beta) that you 
>> might find useful for your use case. I have written small library that 
>> describes client middleware protocol , 
>> some useful middlewares  
>> and HTTP client  that's using these 
>> libraries. 
>>
>> This might solve your problem directly (writing new middleware is 
>> trivial), but it might introduce dependency that you don't want, so I hope 
>> this will provide inspiration on how you would do something similar 
>> yourself. 
>>
>> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:
>>>
>>> Hi
>>>
>>> I want to implement a client middleware - for example: sign the request 
>>> body and add the signature as an HTTP header.
>>> I thought that the best way to do it is to implement a RoundTripper 
>>> interface  which up on 
>>> request, calculate the signature, adds the header, and invoke a "next" 
>>> ToundTripper.
>>>
>>> This could be a very generic implementation, which i can inject to any 
>>> client that uses the standard library http.Client.
>>>
>>> However, I found the following in the doc:
>>>
>>> // RoundTrip should not modify the request, except for
>>> // consuming and closing the Request's Body. RoundTrip may
>>> // read fields of the request in a separate goroutine. Callers
>>> // should not mutate the request until the Response's Body has
>>> // been closed.
>>>
>>>
>>> Is there a standard way to do it?
>>>
>>> Thanks,
>>> Eyal
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: best practices of client middleware

[Eyal Posener]

Good stuff,
So I see that this library wraps the http.Client and doesn't use the 
roundtripper.
Pretty elegant!

I still have two questions about the standard library:

   - Didn't understand yet why it is not allowed to add headers in the 
   roundtripper.
   - Is this a bit strange that the standard library provides a beautiful 
   way to have server middleware, but no way to have client middlewares?
   
Cheers,
Eyal

On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote:
>
> As far as I am aware, there is very little information about best 
> practices regarding client side middlewares. 
>
> I though that having such support is neat idea and I have implemented 
> something (that I use for some time now, though still in beta) that you 
> might find useful for your use case. I have written small library that 
> describes client middleware protocol , 
> some useful middlewares  
> and HTTP client  that's using these 
> libraries. 
>
> This might solve your problem directly (writing new middleware is 
> trivial), but it might introduce dependency that you don't want, so I hope 
> this will provide inspiration on how you would do something similar 
> yourself. 
>
> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:
>>
>> Hi
>>
>> I want to implement a client middleware - for example: sign the request 
>> body and add the signature as an HTTP header.
>> I thought that the best way to do it is to implement a RoundTripper 
>> interface  which up on 
>> request, calculate the signature, adds the header, and invoke a "next" 
>> ToundTripper.
>>
>> This could be a very generic implementation, which i can inject to any 
>> client that uses the standard library http.Client.
>>
>> However, I found the following in the doc:
>>
>> // RoundTrip should not modify the request, except for
>> // consuming and closing the Request's Body. RoundTrip may
>> // read fields of the request in a separate goroutine. Callers
>> // should not mutate the request until the Response's Body has
>> // been closed.
>>
>>
>> Is there a standard way to do it?
>>
>> Thanks,
>> Eyal
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: best practices of client middleware

[Bojan Delić]

As far as I am aware, there is very little information about best practices 
regarding client side middlewares. 

I though that having such support is neat idea and I have implemented 
something (that I use for some time now, though still in beta) that you 
might find useful for your use case. I have written small library that 
describes client middleware protocol , 
some useful middlewares  and 
HTTP 
client  that's using these libraries. 

This might solve your problem directly (writing new middleware is trivial), 
but it might introduce dependency that you don't want, so I hope this will 
provide inspiration on how you would do something similar yourself. 

On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote:
>
> Hi
>
> I want to implement a client middleware - for example: sign the request 
> body and add the signature as an HTTP header.
> I thought that the best way to do it is to implement a RoundTripper 
> interface  which up on 
> request, calculate the signature, adds the header, and invoke a "next" 
> ToundTripper.
>
> This could be a very generic implementation, which i can inject to any 
> client that uses the standard library http.Client.
>
> However, I found the following in the doc:
>
> // RoundTrip should not modify the request, except for
> // consuming and closing the Request's Body. RoundTrip may
> // read fields of the request in a separate goroutine. Callers
> // should not mutate the request until the Response's Body has
> // been closed.
>
>
> Is there a standard way to do it?
>
> Thanks,
> Eyal
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.