[go-nuts] How to limit client IPs in tls listener?

I'm trying to limit which clients are allowed to connect to my tls server by their IPs. I know I can do that after Accept, check their IPs and close the connection if they're not whitelisted. But that means the full tls handshake has to complete before I can do that. Another option is that I c

Re: [go-nuts] How to limit client IPs in tls listener?

hich checks the list of allowed > IPs. > You'll be able to run code before the connection is passed on to > crypto/tls. > Wrap it using https://golang.org/pkg/crypto/tls/#NewListener. > > On 3/15/19 2:10 PM, Glen Huang wrote: > > I'm trying to limit which clien

Re: [go-nuts] How to limit client IPs in tls listener?

t; } > > Then, to use: > > ln, err := net.Listen("tcp", addr) > if err != nil { > log.Fatal(err) > } > aln := &allowedIPsListener{allowed: yourListOfIPs, inner: ln} > tlsln := tls.NewListener(aln, yourTLSConfig) > > // use tlsln &

Re: [go-nuts] How to limit client IPs in tls listener?

So looks like nftables is my only choice then? On Friday, March 15, 2019 at 10:30:28 PM UTC+8, Andrei Tudor Călin wrote: > > That sounds like something a firewall would do, not your Go program. > > On 3/15/19 3:14 PM, Glen Huang wrote: > > Thanks, but if I'm not wrong, t

[go-nuts] Question regarding gob

I planed to use net/rpc with gob, but then found the GitHub issue saying net/rpc is deprecated, and people should be using grpc instead. That leads to the question should I use grpc with gob or stick with protobuf? Google suggests not many people talk about using grpc with gob, any there aren't

Re: [go-nuts] Question regarding gob

hiatus) right now? On Monday, March 25, 2019 at 10:36:12 PM UTC+8, Sameer Ajmani wrote: > > With gRPC, I recommend you use protobuf. > > On Mon, Mar 25, 2019 at 8:18 AM Glen Huang > > wrote: > >> I planed to use net/rpc with gob, but then found the GitHub issue saying &g

[go-nuts] How to determine when to actually use goroutines?

Hi, I'm still pretty new to go. Hope this question isn't too stupid. I'm writing a restful API server, and in order to send a response, I need to query a db to get its content type and then send the actually file that lives on the file system. Now the question is, should I put db.QueryRow and

[go-nuts] Re: How to determine when to actually use goroutines?

either of those things will cause issues, and even if they do, solutions > such as adding indexes to problematic fields or doing caching might help A > LOT more than trying to be more concurrent will. > > > On Monday, July 24, 2017 at 8:34:30 AM UTC-7, Glen Huang wrote: >> >&

[go-nuts] Re: How to determine when to actually use goroutines?

ilable > by searching for those keywords. > > On Tuesday, 25 July 2017 01:34:30 UTC+10, Glen Huang wrote: >> >> Hi, >> >> I'm still pretty new to go. Hope this question isn't too stupid. >> >> I'm writing a restful API server, and in or

[go-nuts] Correct way to track each individual goroutine

I'm writing an image uploading server, and by posting to an url, users can upload an image, and then from another url, they can retrieve it back. The tricky part is that I want to compress the image after uploading. My current design is that uploading is finished as soon as the image is uploade

[go-nuts] Re: Correct way to track each individual goroutine

Thanks for bringing singleflight to my attention. However, if I'm not wrong, it doesn't seem to fully solve the problem. If after uploading, I call singleflight.Do, and pass the file name and the compression function, when users requests a file, should I call singleflight.Do and pass the reques

[go-nuts] Re: Correct way to track each individual goroutine

oh, never thought about that. Initially there will be only server but it's only matter of time I need to scale to multiple servers. I'll probably give redis a shot. Thanks for the suggestion! On Wednesday, July 26, 2017 at 8:33:59 AM UTC+8, Florin Pățan wrote: > > Will the user always end up on

Re: [go-nuts] Correct way to track each individual goroutine

Tue, Jul 25, 2017 at 6:56 AM Glen Huang > > wrote: > >> >> My current design is that uploading is finished as soon as the image is >> uploaded to the server, after which I spawn a goroutine to exec a command >> to do the compression. When the user requests the ima

[go-nuts] How to check if a request was cancelled

I have this simple code in which I try to check if the request was cancelled. But surprisingly, it prints false instead of true in go 1.9. I wonder what's the correct way to check that? package main import ( "context" "log" "net/http" ) func main() { r, _ := http.NewRequest("

[go-nuts] Re: How to check if a request was cancelled

mapäev, 8. november 2017 14:02.13 UTC+2 kirjutas Glen Huang: >> >> I have this simple code in which I try to check if the request was >> cancelled. But surprisingly, it prints false instead of true in go 1.9. >> >> I wonder what's the correct way to check that?

Re: [go-nuts] Re: How to check if a request was cancelled

type > switch; > > _, err := http.DefaultClient.Do(r) > if urlErr, ok := err.(*url.Error); ok { > log.Println(urlErr.Err == context.Canceled) // “true", in your example > } > > //jb > > > On 8 Nov 2017, at 13:11, Glen Huang > > wrote: > > Yes. Thanks fo

Re: [go-nuts] Re: How to check if a request was cancelled

Yep, that's a good way too. Thanks. Ain also posted it on SO. On Wednesday, November 8, 2017 at 8:20:25 PM UTC+8, Jan Mercl wrote: > > On Wed, Nov 8, 2017 at 1:12 PM Glen Huang > > wrote: > > see https://play.golang.org/p/wMJ5PX1x9H > > -- > > -j > -- You

Re: [go-nuts] How to check if a request was cancelled

for another reason, before the > context was cancelled. Whether this matters is of course up to the > application. > > //jb > > >> On 8 Nov 2017, at 13:19, Jan Mercl <0xj...@gmail.com >> <mailto:0xj...@gmail.com>> wrote: >> >> On Wed, Nov

[go-nuts] Problem designing APIs after the compress stdlib

I'm writing a small image processing tool, given an image content, it only does two things: 1. compressing the image content 2. generating a thumbnail (by resizing and then compressing it) I want to model the compressing(the same goes for resizing) after the compress stdlib: you create a compre

[go-nuts] Re: Problem designing APIs after the compress stdlib

Any suggestion how to improve compressor and resizer's APIs? Regards, Glen On Thursday, November 9, 2017 at 12:26:14 PM UTC+8, Glen Huang wrote: > > I'm writing a small image processing tool, given an image content, it only > does two things: > > 1. compressing the imag

[go-nuts] How to mock things without having too big an impact on the source code?

I find that to be able to unit test things in golang, I need to restructure them in an uncomfortable way in order to be able to mock their dependencies. For example, say I want to test this simple http handler: func handleLogIn(w http.ResponseWriter, r *http.Request) { svc := pkg.NewExternalServ

[go-nuts] Re: How to mock things without having too big an impact on the source code?

ervice > } > > > func(h handleLogin)ServeHTTP(w http.ResponseWriter,r *http.Request){ > h.Service.CallThis(r) > } > > You can only write unit tests if you write testable code at first place. > > Le mercredi 15 novembre 2017 03:28:28 UTC+1, Glen Huang a écrit : >> &g

[go-nuts] Doc mentioned it's possible to inspect unexported methods using reflect, but I can't figure out how

Hi, The doc for the method type in the reflect package (https://golang.org/pkg/reflect/#Method) seems to suggest that it's possible to inspect a type's unexported methods: // PkgPath is the package path that qualifies a lower case (unexported) // method name. It is empty for up

Re: [go-nuts] Doc mentioned it's possible to inspect unexported methods using reflect, but I can't figure out how

Thanks for the reply. Hopefully the doc can be changed to avoid confusion. On Sunday, January 21, 2018 at 1:16:04 PM UTC+8, Ian Lance Taylor wrote: > > On Sat, Jan 20, 2018 at 8:43 PM, Glen Huang > wrote: > > > > The doc for the method type in the reflect package > &

[go-nuts] How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

I want to unmarshal a struct that contains embedded structs: type Parent struct { Child P int } type Child struct { Grandchild C int } type Grandchild struct { G int } The problem is that Grandchild defines its own UnmarshalJSON method, and that means Parent inherits it and breaks json

[go-nuts] Re: How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

After thinking more about it, I start to feel that maybe using embedded structs is generally a bad idea with dealing with json? Is the correct solution here to use explicit fields? BTW, happy New Year everyone. On Tuesday, December 31, 2019 at 6:21:07 PM UTC+8, Glen Huang wrote: > > I w

[go-nuts] Re: How to correctly json.Unmarshal struct whose embedded structs define UnmarshalJSON

you "inherit" these methods and you don't want this to happe Given the case above, I'm wondering if embedding + not overriding method is possible? On Thursday, January 2, 2020 at 9:19:23 AM UTC+8, Ben Bullock wrote: > > > > On Tuesday, 31 December 2019 19:21:07 UT

[go-nuts] Directly assign map[string]int to map[string]interface{}?

Hi, I have a function that accepts an argument of type map[string]interface{}, and I also have a value of type map[string]int. Currently it seems I can't directly pass the value to the function. Is there anyway I can directly coerce it or a new value of the exact matching type must be created

[go-nuts] Re: Directly assign map[string]int to map[string]interface{}?

Another slightly related topic: switch v := i.(type) { case map[string]interface{}, map[string]int: fmt.Print(v) } Ideally v is of type map[string]interface{}, but it's interface{} instead. On Sunday, February 23, 2020 at 5:12:27 PM UTC+8, Glen Huang wrote: > > Hi, > >

Re: [go-nuts] Re: Directly assign map[string]int to map[string]interface{}?

x27;t possible. > > On Sun, Feb 23, 2020 at 10:24 AM Glen Huang > wrote: > >> Another slightly related topic: >> >> switch v := i.(type) { >> case map[string]interface{}, map[string]int: >> fmt.Print(v) >> } >> >> Ideally v is of type

[go-nuts] Any reason why this type conversion is not allowed?

Given type Data []byte s := [][]byte{{1},{2}} I wonder why this conversion isn't allowed? []Data(s) Seems pretty straightforward. Maybe I miss some edge cases where things won't square? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsu

Re: [go-nuts] Any reason why this type conversion is not allowed?

't emit a single conversion of this type, since one structure isn't > safely coercible to the other type. This would be along the lines of > reinterpret_cast<> in c++, which can corrupt memory. > > > On Mon, Apr 13, 2020 at 6:56 PM Glen Huang > > w

Re: [go-nuts] Any reason why this type conversion is not allowed?

@lan @Shulhan Thanks. Glad to know the design goal much better. On Tuesday, April 14, 2020 at 1:07:36 PM UTC+8, Ian Lance Taylor wrote: > > On Mon, Apr 13, 2020 at 6:56 PM Glen Huang > > wrote: > > > > Given > > > > type Data []byte > > s := [][

[go-nuts] Possible to make go not touch the built file if it builds purely from cache?

I have a makefile where upon a new go binary being built, it builds some other stuff that is not go related. The go binary is unconditionally built with a FORCE prerequisite, so the go build command always runs, but that command always updates the output binary, which leads to downstream being

Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

to use go build directly. move-if-change sounds like a good approach, will come in handy when there is no need to cross compile, thanks for the tip. On Thursday, April 16, 2020 at 4:09:27 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Apr 15, 2020 at 4:55 AM Glen Huang > > wrote: > >

Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

Thanks, as mentioned in the previous reply, this is what I end up using. On Thursday, April 16, 2020 at 10:25:03 AM UTC+8, Shulhan wrote: > > > > On 15 Apr 2020, at 18.55, Glen Huang > > wrote: > > > > I have a makefile where upon a new go binary being built, it b

Re: [go-nuts] What's go's convention for specifying the equivolent of configure --prefix?

> Whats wrong with const? Const is the ideal choice, but how do users of my program specify the path when they compile it? > And could not be global var then? Using var loses the guarantee that the path won’t be changed, and the go compiler can no longer optimize as much I presume? -- You

Re: [go-nuts] What's go's convention for specifying the equivolent of configure --prefix?

@m.shulhan @hervinhioslash Thanks for the suggestion. I agree that using a runtime mechanism like env vars or command line flag can solve this problem. But the path value is for internal use, it should be customized only by the system administrators or package managers who determine where to in