[go-nuts] Re: Draining http response bodies

[Amnon]

Added issue https://github.com/golang/go/issues/48860

On Thursday, 7 October 2021 at 08:36:25 UTC+1 Amnon wrote:

> Is it necessary for a http client to fully read the http response body?
>
> Opinion on the Go forums seems divided 
> https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594
>
> But a simple benchmark https://play.golang.org/p/5JDWYbRe0lD
> suggests that leaving unread data in the response body will prevent 
> the connection being reused, and much slower performance.
>
> The documentation https://pkg.go.dev/net/http states:
>
> "The client must close the response body when finished with it:"
>
> The following example does include a call to io.ReadAll(resp.Body) 
> but it does not spell out whether there would be a performance penalty
> for failing to read the entire body.
>
> It would be good if the standard library documentation was a bit more 
> explicit here.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1169be3d-e5a5-4d15-aded-a7f795e5a25an%40googlegroups.com.

[go-nuts] [ANN] Pure Go NFSv4 client

[Alex Besogonov]

Hi!

Here's my pure Go NFSv4 client. It's designed to work with Amazon EFS 
(Elastic FileSystem) but also can work against Linux kNFSD or Ganesha (in 
fact, Ganesha is used for integration testing).

Enjoy: https://github.com/Cyberax/go-nfs-client

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5cd43d10-011f-4df4-a76b-c37144ef0793n%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

> The io.ReadAll function and the io.Reader interface Read method are not 
the same, don't conflate them.
Thank you for stressing that point, but I don't think that I conflate them. 
Maybe I wrong, but I believe that many entries in "io" package share 
decriptions that states "A successful call returns err == nil, not err == 
EOF. Because ReadAll is defined to read from src until EOF, it does not 
treat an EOF from Read as an error to be reported.", so I quote it just 
because it was at my hand.

> Have you read https://go.dev/blog/errors-are-values by Rob Pike?
Thank you very much Michael, I read few things about errors in Go, but 
never that blog post. Now I need for my job to process few files in Go, so 
I need to read "io" first, but after that, I will read this mail. In some 
sense I'm a fan of Rob Pike blog posts, articles and talks. Hard to say 
why, maybe he is "no nonsense guy"?

Best
Kamil
czwartek, 7 października 2021 o 15:13:22 UTC+2 michael...@gmail.com 
napisał(a):

> Kamil,
> Have you read https://go.dev/blog/errors-are-values by Rob Pike?  
> Wrapping my head around the concept that an error is simply a value 
> returned from a function was tremendously helpful when I had questions 
> along the same lines as yours.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a44f9c63-cea5-4325-a872-83c71a5e28a5n%40googlegroups.com.

[go-nuts] [security] Go 1.17.2 and Go 1.16.9 are released

[Michael Knyszek]

Hello gophers,

We have just released Go versions 1.17.2 and 1.16.9, minor point releases.

These minor releases include a security fix according to the new security
policy (#44918 ).

When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
passing very large arguments can cause portions of the module to be
overwritten with data from the arguments.


If using wasm_exec.js to execute WASM modules, users will need to replace
their copy (as described in
https://golang.org/wiki/WebAssembly#getting-started) after rebuilding any
modules.


This is issue #48797  and
CVE-2021-38297. Thanks to Ben Lubar for reporting this issue.


View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.17.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.17.2" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
Michael and Heschi for the Go team

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN%3D%2BcNobSW%3DrQF_5LhX%2BnrU4XooL6QbUpvA77qf5R8ybWmGOiQ%40mail.gmail.com.

[go-nuts] I am looking for a full-time 100% REMOTE Sr. Golang developer.

[victor baldi]

The company is in software development. Main office is in Boston, MS. 
Working remote is no issue!!
See attached job description.
If interested please email to: victor.ba...@validity.com 

Thank you!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1c4f8b3f-15e8-4358-8d23-671ba78d5a40n%40googlegroups.com.


Sr. Software Engineer (Go).pdf
Description: Adobe PDF document

[go-nuts] Re: copy resp.Body to *bytes.Buffer

['Ross Light' via golang-nuts]

Use io.Copy . Example: 
https://play.golang.org/p/89KkmplfZ4M

-Ross

On Thursday, October 7, 2021 at 5:13:17 AM UTC-7 RS wrote:

> How can I copy resp.Body  to a *bytes.Buffer?
>
> I am new to go. 
> resp.Body is the response which I get from client.Do, and is of type 
> *http.Response

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1f10a859-c77f-4f66-95ba-f799fd0addd0n%40googlegroups.com.

[go-nuts] xml to json, parsing xml

[RS]

What is the best approach to convert xml to json? 
However I need above all to parse a very complex xml to see if related 
properties are existing. 
I thought maybe converting it to Json maybe make it easier. 


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d65ea5e3-6705-4438-9738-e3dbc7f373bdn%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Michael Ellis]

Kamil,
Have you read https://go.dev/blog/errors-are-values by Rob Pike?  Wrapping 
my head around the concept that an error is simply a value returned from a 
function was tremendously helpful when I had questions along the same lines 
as yours.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/724b763c-cd5d-4c9c-83f2-8c08cb739887n%40googlegroups.com.

[go-nuts] copy resp.Body to *bytes.Buffer

[RS]

How can I copy resp.Body  to a *bytes.Buffer?

I am new to go. 
resp.Body is the response which I get from client.Do, and is of type 
*http.Response

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8650dc32-bfc7-4156-a2ca-4a1041fd3e9an%40googlegroups.com.

Re: [go-nuts] sending server response to a client by w responseWriter

['Axel Wagner' via golang-nuts]

 On Thu, Oct 7, 2021 at 1:43 PM RiSi  wrote:

> if error happens by io.Copy, can I set the status Code of w after io.Copy?
>

No. io.Copy might have already written parts of the body. You can't set the
status after parts of the body have been written.


>
>
> Am Do., 7. Okt. 2021 um 13:41 Uhr schrieb RiSi :
>
>>
>> *w.Header().Set("Content-Type", "application/xml")*
>>
>> *_, err:=io.Copy(w,src) *
>>
>> *if err!=nil{*
>> *re := { Message: "Error happened",}*
>>
>>
>>
>> *w.Header().Set("Content-Type", "application/json")w.WriteHeader(599)
>> //sample status codeerr = json.NewEncoder(w).Encode(re)*
>> *}//if*
>>
>> *the part after err!=nil should be removed?*
>>
>> Am Do., 7. Okt. 2021 um 13:29 Uhr schrieb Axel Wagner <
>> axel.wagner...@googlemail.com>:
>>
>>> As I said in your last thread:
>>> https://groups.google.com/g/golang-nuts/c/I5gwXr1kOA0/m/oIVYRgBoAQAJ
>>> What you want is impossible, based on how HTTP works. The status of a
>>> request must be determined *before* any of the body is written. So, if
>>> writing the body fails, there is nothing more you can do - you can only
>>> ignore that. And it's not an abnormal condition for the writing of a body
>>> to fail, as clients may disconnect at any time.
>>>
>>> The best you can do is
>>> a) write the body to an in-memory buffer, to make sure all bytes that
>>> need to be written are correctly determined,
>>> b) then set tany headers (e.g. content-type) and status as appropriate
>>> and
>>> c) write out the body, ignoring any errors - or at best, increment a
>>> metric or logging it.
>>>
>>> That is, IMO, the best you can do with HTTP. There is no guarantee the
>>> body can be written, before you try do it and you can't set the status
>>> after you start writing the body. But if the actual *Write* fails (as
>>> opposed to the Read part of an io.Copy) you can at least be reasonably sure
>>> that the problem is some network issue or client disconnect you can't do
>>> anything about, so it's fine to ignore (from an application perspective).
>>>
>>> On Thu, Oct 7, 2021 at 1:12 PM RS  wrote:
>>>
 Best practice in following scenario:

 In my func for an endpoint (handler) with  func hello(w
 http.ResponseWriter, req *http.Request)
 I call another server get the resp.Body (Body io.ReadCloser) and want
 to write this Body  in w (ResponseWriter ).
 What is best practice?
 I have already copied directly Body to w via io.Copy.
 I want but make sure that the whole body is sent to client.
 With io.Copy I am not sure if this is guaranteed.
 And I would like to set status to 500 in case io.Copy returns err.

 Could you please help me on this?


 --
 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.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/5f0e7131-2625-452d-9861-51f5e42345d8n%40googlegroups.com
 
 .

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH9A%2B-ykfmZ8U0xy1Hn8Oo1f7vhVmMuiOLJxJbb%3D8KP1g%40mail.gmail.com.

Re: [go-nuts] sending server response to a client by w responseWriter

[RiSi]

if error happens by io.Copy, can I set the status Code of w after io.Copy?


Am Do., 7. Okt. 2021 um 13:41 Uhr schrieb RiSi :

>
> *w.Header().Set("Content-Type", "application/xml")*
>
> *_, err:=io.Copy(w,src) *
>
> *if err!=nil{*
> *re := { Message: "Error happened",}*
>
>
>
> *w.Header().Set("Content-Type", "application/json")w.WriteHeader(599)
> //sample status codeerr = json.NewEncoder(w).Encode(re)*
> *}//if*
>
> *the part after err!=nil should be removed?*
>
> Am Do., 7. Okt. 2021 um 13:29 Uhr schrieb Axel Wagner <
> axel.wagner...@googlemail.com>:
>
>> As I said in your last thread:
>> https://groups.google.com/g/golang-nuts/c/I5gwXr1kOA0/m/oIVYRgBoAQAJ
>> What you want is impossible, based on how HTTP works. The status of a
>> request must be determined *before* any of the body is written. So, if
>> writing the body fails, there is nothing more you can do - you can only
>> ignore that. And it's not an abnormal condition for the writing of a body
>> to fail, as clients may disconnect at any time.
>>
>> The best you can do is
>> a) write the body to an in-memory buffer, to make sure all bytes that
>> need to be written are correctly determined,
>> b) then set tany headers (e.g. content-type) and status as appropriate and
>> c) write out the body, ignoring any errors - or at best, increment a
>> metric or logging it.
>>
>> That is, IMO, the best you can do with HTTP. There is no guarantee the
>> body can be written, before you try do it and you can't set the status
>> after you start writing the body. But if the actual *Write* fails (as
>> opposed to the Read part of an io.Copy) you can at least be reasonably sure
>> that the problem is some network issue or client disconnect you can't do
>> anything about, so it's fine to ignore (from an application perspective).
>>
>> On Thu, Oct 7, 2021 at 1:12 PM RS  wrote:
>>
>>> Best practice in following scenario:
>>>
>>> In my func for an endpoint (handler) with  func hello(w
>>> http.ResponseWriter, req *http.Request)
>>> I call another server get the resp.Body (Body io.ReadCloser) and want to
>>> write this Body  in w (ResponseWriter ).
>>> What is best practice?
>>> I have already copied directly Body to w via io.Copy.
>>> I want but make sure that the whole body is sent to client.
>>> With io.Copy I am not sure if this is guaranteed.
>>> And I would like to set status to 500 in case io.Copy returns err.
>>>
>>> Could you please help me on this?
>>>
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/5f0e7131-2625-452d-9861-51f5e42345d8n%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJE-_Rd%2B%3DLDyBRGDcj4DV9URp9%2BNLMJsY0QgRszaJDSg9aCPwA%40mail.gmail.com.

Re: [go-nuts] sending server response to a client by w responseWriter

[RiSi]

*w.Header().Set("Content-Type", "application/xml")*

*_, err:=io.Copy(w,src) *

*if err!=nil{*
*re := { Message: "Error happened",}*



*w.Header().Set("Content-Type", "application/json")w.WriteHeader(599)
//sample status codeerr = json.NewEncoder(w).Encode(re)*
*}//if*

*the part after err!=nil should be removed?*

Am Do., 7. Okt. 2021 um 13:29 Uhr schrieb Axel Wagner <
axel.wagner...@googlemail.com>:

> As I said in your last thread:
> https://groups.google.com/g/golang-nuts/c/I5gwXr1kOA0/m/oIVYRgBoAQAJ
> What you want is impossible, based on how HTTP works. The status of a
> request must be determined *before* any of the body is written. So, if
> writing the body fails, there is nothing more you can do - you can only
> ignore that. And it's not an abnormal condition for the writing of a body
> to fail, as clients may disconnect at any time.
>
> The best you can do is
> a) write the body to an in-memory buffer, to make sure all bytes that need
> to be written are correctly determined,
> b) then set tany headers (e.g. content-type) and status as appropriate and
> c) write out the body, ignoring any errors - or at best, increment a
> metric or logging it.
>
> That is, IMO, the best you can do with HTTP. There is no guarantee the
> body can be written, before you try do it and you can't set the status
> after you start writing the body. But if the actual *Write* fails (as
> opposed to the Read part of an io.Copy) you can at least be reasonably sure
> that the problem is some network issue or client disconnect you can't do
> anything about, so it's fine to ignore (from an application perspective).
>
> On Thu, Oct 7, 2021 at 1:12 PM RS  wrote:
>
>> Best practice in following scenario:
>>
>> In my func for an endpoint (handler) with  func hello(w
>> http.ResponseWriter, req *http.Request)
>> I call another server get the resp.Body (Body io.ReadCloser) and want to
>> write this Body  in w (ResponseWriter ).
>> What is best practice?
>> I have already copied directly Body to w via io.Copy.
>> I want but make sure that the whole body is sent to client.
>> With io.Copy I am not sure if this is guaranteed.
>> And I would like to set status to 500 in case io.Copy returns err.
>>
>> Could you please help me on this?
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/5f0e7131-2625-452d-9861-51f5e42345d8n%40googlegroups.com
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJE-_RciZS93CsJYDcFwv77URV4dF1TiGppre5rCvQ42ba6jvg%40mail.gmail.com.

Re: [go-nuts] sending server response to a client by w responseWriter

['Axel Wagner' via golang-nuts]

As I said in your last thread:
https://groups.google.com/g/golang-nuts/c/I5gwXr1kOA0/m/oIVYRgBoAQAJ
What you want is impossible, based on how HTTP works. The status of a
request must be determined *before* any of the body is written. So, if
writing the body fails, there is nothing more you can do - you can only
ignore that. And it's not an abnormal condition for the writing of a body
to fail, as clients may disconnect at any time.

The best you can do is
a) write the body to an in-memory buffer, to make sure all bytes that need
to be written are correctly determined,
b) then set tany headers (e.g. content-type) and status as appropriate and
c) write out the body, ignoring any errors - or at best, increment a metric
or logging it.

That is, IMO, the best you can do with HTTP. There is no guarantee the body
can be written, before you try do it and you can't set the status after you
start writing the body. But if the actual *Write* fails (as opposed to the
Read part of an io.Copy) you can at least be reasonably sure that the
problem is some network issue or client disconnect you can't do anything
about, so it's fine to ignore (from an application perspective).

On Thu, Oct 7, 2021 at 1:12 PM RS  wrote:

> Best practice in following scenario:
>
> In my func for an endpoint (handler) with  func hello(w
> http.ResponseWriter, req *http.Request)
> I call another server get the resp.Body (Body io.ReadCloser) and want to
> write this Body  in w (ResponseWriter ).
> What is best practice?
> I have already copied directly Body to w via io.Copy.
> I want but make sure that the whole body is sent to client.
> With io.Copy I am not sure if this is guaranteed.
> And I would like to set status to 500 in case io.Copy returns err.
>
> Could you please help me on this?
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5f0e7131-2625-452d-9861-51f5e42345d8n%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEi%2Bbum_%2BZmhgj3VvaxsCHJCs61G84g9Xg2tQ7Cggezww%40mail.gmail.com.

[go-nuts] sending server response to a client by w responseWriter

[RS]

Best practice in following scenario:

In my func for an endpoint (handler) with  func hello(w 
http.ResponseWriter, req *http.Request) 
I call another server get the resp.Body (Body io.ReadCloser) and want to 
write this Body  in w (ResponseWriter ).
What is best practice?
I have already copied directly Body to w via io.Copy. 
I want but make sure that the whole body is sent to client. 
With io.Copy I am not sure if this is guaranteed. 
And I would like to set status to 500 in case io.Copy returns err. 

Could you please help me on this?


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f0e7131-2625-452d-9861-51f5e42345d8n%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

>
> I'm not sure what you mean when you say that io.EOF is not treated as an
> error.  io.EOF is an error: it implements the error interface, and is
> returned as the error value by methods such as Read.


I am mediocre at best at programming and I'm quite a picky person, so I
just have a problem with wrapping my head around texts like this below,
which is a documentation of io.ReadAll. Nothing more.

ReadAll reads from r until an error or EOF and returns the data it read. A
> successful call returns err == nil, not err == EOF. Because ReadAll is
> defined to read from src until EOF, it does not treat an EOF from Read as
> an error to be reported.
>

This mental dissonans is probably caused by the simple fact that I think
about error as information that something doesn't work as it should, but
arriving at the end of the file means that we are where we should be.

But that doesn't mean that it's not an error.  The Read failed.  Every
> failure is reported via an error.  For the case in which Read fails because
> it reaches the end of the file, the error that it returns is io.EOF.
>

Thank you very much. I will try to digest that io.EOF means that Read
fails, so this is an error of Read method/function. I never think about it
that way.

Best
Kamil

czw., 7 paź 2021 o 06:25 peterGo  napisał(a):

> Kamil,
>
> A Go interface implements a particular behavior. For example, io.Reader is
> the interface that wraps the basic Read method.
>
> type Reader interface {
> Read(p []byte) (n int, err error)
> }
>
> The outcome of the Read method ranges from good to catastrophic failure.
> The outcome is reported in the err error type return value. The err return
> value for good is nil. For a finite stream of data, a particular outcome of
> interest is end-of-file.
>
> var EOF = errors.New("EOF")
>
> io.EOF is the error returned by Read when no more input is available.
>
> See package io.
> https://pkg.go.dev/io
>
> Peter
>
> On Wednesday, October 6, 2021 at 5:35:11 PM UTC-4 kziem...@gmail.com
> wrote:
>
>> Hello,
>>
>> I currently read about "io" package and again I read that "io.EOF" is not
>> treated as error, since it is what you expect to end file, which is almost
>> tautology. At the same time it satisfies error interface and is created
>> busing errors.New function.
>>
>> I understand why this is done, doing it other way would probably make
>> serious mess in the code, but pedantic said of me is unsettled by this.
>> Does any experience Gopher can give my advice how to think about situation
>> when some object satisfy interface, but it is exception that proves the
>> rule? I should just get used to it, or is it some better way of thinking?
>>
>> Best
>> Kamil
>>
>> sobota, 4 września 2021 o 23:28:20 UTC+2 Brian Candler napisał(a):
>>
>>> Ah, I missed the bit where it says "Flag syntax is xyz (set)
>>> or -xyz (clear) or xy-z (set xy, clear z)."  You're quite right, there's a
>>> much simpler way:
>>> https://play.golang.org/p/upupUQUcsR8
>>>
>>> On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com
>>> wrote:
>>>
 Thank you for your answer and opinion Briana Candler.

 I ask about unset only because of the cryptic text, at least to me, in
 the description of RE2 (https://github.com/google/re2/wiki/Syntax).
 From practical point of view, your solutions look good.

 I try to google about changes in examples in Go's stdlib, maybe this
 can be done?

 Best
 Kamil

 pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):

> I believe (?m) applies to the current group only; if you want to
> "unset" it then start a separate group.
> https://play.golang.org/p/wT_ZTrUSABL
>
> And I think you're right, there's no need to have capture groups for
> FindIndex.
>
> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com
> wrote:
>
>> Hello,
>>
>> My struggles with regexp is going and I have another problem. I read
>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax)
>> and I still not sure if I understand one example from regexp package.
>>
>> In example in method func (*Regexp) FindIndex (
>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex
>> ) we have line
>>
>> pattern := regexp.MustCompile(`(?m)(?P\w+):\s+(?P\w+)$`)
>>
>> Does (?m) set value of flag m to true and if I want set it to false I
>> should write (?-m) or not? By default m should be false, but as example 
>> it
>> is fine.
>>
>> As a side note, this regular expression is used in other examples,
>> when we need  and , but looks unnecessary complex for method
>> FindIndex. I guess
>> `(?m)\w+:\s+\w+$`
>> would work fine. Am I wrong?
>>
>> Best
>> Kamil
>>
>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>
>>> Kurtis Rader, 

[go-nuts] Draining http response bodies

[Amnon]

Is it necessary for a http client to fully read the http response body?

Opinion on the Go forums seems divided 
https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594

But a simple benchmark https://play.golang.org/p/5JDWYbRe0lD
suggests that leaving unread data in the response body will prevent 
the connection being reused, and much slower performance.

The documentation https://pkg.go.dev/net/http states:

"The client must close the response body when finished with it:"

The following example does include a call to io.ReadAll(resp.Body) 
but it does not spell out whether there would be a performance penalty
for failing to read the entire body.

It would be good if the standard library documentation was a bit more 
explicit here.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/14603faa-cf60-4547-9015-8ac14083fc54n%40googlegroups.com.

[go-nuts] Better documentation needed on draining http request bodies

[Amnon]

Is it necessary to drain a http client to fully read the http response body?

Opinion on the Go forums seems 
divided 
https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594

But a simple benchmark https://play.golang.org/p/5JDWYbRe0lD
suggests that leaving unread data in the response body will prevent 
the connection being reused, and much slower performance.

The documentation https://pkg.go.dev/net/http states:

The client must close the response body when finished with it:
But it is silent on the question of whether the client should consume the 
entire body.

It would be good if the standard library documentation was a bit more 
explicit here.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2a29b5dc-e785-420f-bf58-72fb47470ba4n%40googlegroups.com.