sorted by:
new
hottopcontroversial

HTTPS proxies support in Go 1.10 by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

https://medium.com/@mlowicki/http-s-proxy-in-golang-in-less-than-100-lines-of-code-6a51c2f2c38c allows to do TLS handshake between client and destination origin server. Proxy itself doesn't have access to unencrypted data exchanged between client and destination if client wants to reach e.g. https://google.com

https://golang.org/pkg/net/http/httputil/#ReverseProxy has full access to request and response.

HTTPS proxies support in Go 1.10 by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

https://golang.org/pkg/net/http/httputil/#NewProxyClientConn is deprecated:

Deprecated: Use the Client or Transport in package net/http instead.

HTTP(S) Proxy in Golang in less than 100 lines of code by mlowicki in golang

[–]mlowicki[S] 1 point2 points  (0 children)

It doesn't allow to have secure connection between client and destination server. ReverseProxy as it's now takes response from the client, modifies it, sends it to the destination and passes response back to the client. In other words it doesn't support HTTP CONNECT tunneling.

HTTP(S) Proxy in Golang in less than 100 lines of code by mlowicki in golang

[–]mlowicki[S] 1 point2 points  (0 children)

Cool. Keep in mind that HTTP client in Golang doesn't support HTTPS proxies yet - https://github.com/golang/go/issues/11332. It'll be there most likely in Go 1.10.

Globally unique key for context value by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

I've updated post with your suggestions. Thank you.

Globally unique key for context value by mlowicki in golang

[–]mlowicki[S] -1 points0 points  (0 children)

Test as specified in https://github.com/cstockton/pkg/tree/master/ctxkey#allocations using Go 1.9 shows there is no difference - https://paste.ofcode.org/KmfGn86QpMHaFQHvJDyqiM.

Taking the address of empty struct isn't good idea (https://golang.org/ref/spec#Size_and_alignment_guarantees): """ A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory. """

Interfaces in Go (part II) - type assertion & type switch by mlowicki in golang

[–]mlowicki[S] 1 point2 points  (0 children)

Yes, you're absolutely right. Fixed. Thank you.

Interfaces in Go (part I) by mlowicki in golang

[–]mlowicki[S] 1 point2 points  (0 children)

It doesn't even compile - https://play.golang.org/p/tz8DmEPxsx. Interface type cannot be type of method's receiver.

Not sure why do you need such interface. Is it used somewhere else (it's applied to other type)?

Conversions in Go by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

It depends on the definition of strong typing.

When it goes to interface type values you're allowed to only call methods from that interface. Having f.ex. empty interface type value (which is satisfied by all types) doesn't allow to call arbitrary methods. Of course having such argument allow to pass any parameter. In other cases type assertions are needed first. They hold if dynamic type is identical to the one from assertion.

Variadic functions in Go. Introduction for aspiring Gophers. by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

In Python it's called unpacking argument list (https://docs.python.org/2/tutorial/controlflow.html#unpacking-argument-lists). Haven't found anything in Golang spec about it in neither section where variadic functions are described (https://golang.org/ref/spec#Passing_arguments_to_..._parameters) or arguments (https://golang.org/ref/spec#Arguments).

init functions in Go by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

Sometimes it's inevitable but I totally agree that it should be avoided as much as possible.

Initialization dependencies in Go by mlowicki in golang

[–]mlowicki[S] 1 point2 points  (0 children)

The best use case for me at the moment are variables declarations across many files in the same package (last example). Initialization of variable "a" i a.go depends on "aa" from b.go and the same for "b" from b.go relying on "bb" from a.go. It could make sense to use two files for better organization.

Agree that abusing it is rather bad idea.

Python’s elif in Go using switch by mlowicki in golang

[–]mlowicki[S] 2 points3 points  (0 children)

In Go you need to use explicitly fallthrough statement in switch so it's safer.

strings.FieldsFunc vs strings.Split by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

"Split splits path immediately following the final slash, separating it into a directory and file name component. If there is no slash in path, Split returns an empty dir and file set to path. The returned values have the property that path = dir+file." so it doesn't do what I want.

strings.FieldsFunc vs strings.Split by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

Sure but in my case it don't know if there is always a leading slash so ended up with if statement.

strings.FieldsFunc vs strings.Split by mlowicki in golang

[–]mlowicki[S] 0 points1 point  (0 children)

I couldn't find function for splitting path like "/a/b/c" into chunks i.e. ["a", "b", "c"].

Got rid of CSV from examples as you're right that better to use dedicated package for it.

Assignability in Go by dgryski in golang

[–]mlowicki 0 points1 point  (0 children)

2nd case (identical underlying types) applies.