On Wed, Feb 6, 2019 at 7:56 AM Robert Engels <reng...@ix.netcom.com> wrote:
>
> 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.
Reader.Len() should give how much you can read from the reader, so
for a buffer, it should return the unread portion. If you have a
reader that loads its chunks as needed and it knows the total length,
that interpretation of Len() is still correct. If you have a Reader
that doesn't know the length, then it should not implement Len().
>
> 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.
Len() is not a private API, it has fairly well-understood and agreed
upon semantics, so I think for this case it is safe to use it without
much negative effect. The http.Request could use a redesign though.
>
> > 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.
--
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.
