But is it really? If you read the description for Len() on bytes.Buffer it is
the length of unread portion. But that doesn’t mean the buffer isn’t just a
portion of the entire body - it can be a chunk which is continually reloaded.
This is the danger in using private APIs publically based upon the existence of
a method - it leads to very brittle code - and there are almost certainly
better ways to design it to avoid these issues. If the core api is not
expressive enough then it will be more difficult.
> On Feb 6, 2019, at 8:30 AM, Burak Serdar <bser...@ieee.org> wrote:
>
>> On Wed, Feb 6, 2019 at 5:15 AM Robert Engels <reng...@ix.netcom.com> wrote:
>>
>> I see now, but if that can be the case, shouldn’t the Body be documented
>> that the Reader may be a ReaderWithLen, and the consumer is free to type
>> check/cast? If not, you are using internal details that you should not be.
>
> Yes, the documentation should say if the reader has a Len() method it
> would be used to set the ContentLength. Len is no longer an internal
> detail then.
>
>>
>> This is a problem with Go in general. Because the returned object
>> “implements” some interface because it happens to have the required method,
>> doesn’t mean it was designed to be used that way, or that it has the
>> required semantics - unless documented to have them.
>
> I agree with you there. Len() is straight forward, but in general just
> because a function is named something doesn't mean it'll do the same
> thing for all implementations. On the other end of the spectrum is
> Java-like interfaces where you want explicit inheritance of a specific
> interface. I don't know if there's anything in between, but I like
> Go's approach much better.
>
>>
>> On Feb 6, 2019, at 2:22 AM, Matteo Biagetti <matteo.biage...@gmail.com>
>> wrote:
>>
>> Make sense, thanks for explanation
>>
>>
>>
>> Il giorno mercoledì 6 febbraio 2019 07:28:54 UTC+1, Burak Serdar ha scritto:
>>>
>>> On Tue, Feb 5, 2019 at 8:13 PM robert engels <ren...@ix.netcom.com> wrote:
>>>>
>>>> That’s what I was trying to point out. Your design is not correct. The
>>>> Body is a Reader, not a Buffer - the length of the request/body may be
>>>> indeterminate - that is, a stream. Attempting to get the length of an
>>>> underlying buffer is not only probably not possible, but not correct in
>>>> many situations.
>>>
>>> The length of the body *may* be indeterminate, and if that's the case,
>>> the underlying Reader will not have a Len method. The design is to
>>> handle the case where the underlying Reader is a Buffer with a Len
>>> method. If the Reader has Len, then the NopCloser derived from that
>>> will also have a Len, and NewRequest can set the content length. If
>>> the Reader does not have Len, then the content length is unknown.
>>>
>>>>
>>>> There is a reason the Body is a ReaderCloser and not a buffer. It is part
>>>> of the http specification.
>>>>
>>>> On Feb 5, 2019, at 9:00 PM, Burak Serdar <bse...@ieee.org> wrote:
>>>>
>>>> On Tue, Feb 5, 2019 at 7:00 PM Robert Engels <ren...@ix.netcom.com> wrote:
>>>>
>>>>
>>>> Shouldn’t you just be taking the content length from the header if
>>>> forwarding the same body. There is no need for the length of the body.
>>>>
>>>>
>>>> True. What I was suggesting is a fix for the general case.
>>>>
>>>>
>>>> On Feb 5, 2019, at 6:53 PM, Burak Serdar <bse...@ieee.org> wrote:
>>>>
>>>> On Tue, Feb 5, 2019 at 5:18 PM Dan Kortschak <d...@kortschak.io> wrote:
>>>>
>>>> Personally, I think this is a bug in the behaviour of NewRequest. See h
>>>> ttps://github.com/golang/go/issues/18117 for some additional context.
>>>>
>>>>
>>>> Agreed. One solution could be to have:
>>>>
>>>> type HasLen interface {
>>>> int Len()
>>>> }
>>>>
>>>> Then have NopCloser return a nopCloser with len if the underlying
>>>> implementation has len, with the obvious changes to NewRequest.Ugly,
>>>> but can be done without API changes.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, 2019-02-05 at 05:18 -0800, matteo....@gmail.com wrote:
>>>> I've the following situation:
>>>> I proxy a request to another server and when I made a POST and create
>>>> a new
>>>> request, the contentLength is zero:
>>>>
>>>> req2, _ := http.NewRequest(req.Method, newApiUrl , req.Body)
>>>> fmt.Println("New request from body:", req2.ContentLength) //
>>>> print 0
>>>>
>>>> Checking in the source code of the NewRequest func Body don't respect
>>>> some
>>>> interface and populate the ContentLength field.
>>>>
>>>> Could be a bug? Which could be a valid approach in order to create a
>>>> new
>>>> request from an existing one and correct set the Body length?
>>>>
>>>> A working example here:
>>>>
>>>> https://play.golang.org/p/SvCDLj0NrXb
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>
>> --
>> 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.
>>
>> --
>> 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.
--
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.
