[go-nuts] What if OrangeFS and AMD's HSA embedded into the golang language?
I have recently been reflecting about OrangeFS and AMD's HSA and how they eventually reach golang users. That implies somewhere there will be a cgogen generated wrapper for them somehow, then they will be used. What if OrangeFS' and HSA were deeply embedded into the go language themselves in a transparent fashion? That way we could get parallel file operations and parallel distributed operations from accessible hardware almost transparently. It would be great if zero-configuration would be possible, but I understand it's not optimal. -- 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.
[go-nuts] Re: Go 1.7 Release Candidate 6 is released
Ok so yes I recently installed clang on this archlinux box. The previous go binaries were built with gcc/g++. So to clarify and save others time: 1)to build using gcc/g++: CC=/usr/bin/gcc CXX=/usr/bin/g++ GOROOT_BOOTSTRAP=/root/go1.7rc5 ./make.bash 2)to build using clang/clang++: CC=/usr/bin/clang CXX=/usr/bin/clang++ GOROOT_BOOTSTRAP=/root/go1.7rc5 ./make.bash By explicitly setting those CC and CXX variables, I was able to revert to my original gcc/g++ built golang binaries in order to be consistent since my earlier binaries were built with gcc/g++ I prefer to stay on that path for the moment. On Wednesday, August 10, 2016 at 10:00:37 AM UTC-4, David Marceau wrote: > > when I install from sources straight from git checkout go1.7rc6 > go1.7rc6 FAILS on Asus Z97-A-USB31 motherboard with intel i5-4590, > "../misc/cgo/testsanitizers" > it core dumps and doesn't give me the success message to start using it as > the previous go1.7rc[1-4] did. > signal: segmentation fault (core dumped) > FAIL: msan > FAIL: msan2 > FAIL: msan3 > FAIL: msan4 > ... FAILED > > > To contrast this, Go1.7rc6 does succeed on another much older motherboard > Dell Inc. Vostro 430/054KM3, BIOS 2.2.0. > > > On Monday, August 8, 2016 at 4:44:40 PM UTC-4, Chris Broadfoot wrote: >> >> Hello gophers, >> >> We have just released go1.7rc6, a release candidate for Go 1.7. >> Some say that it's the best one yet. >> It is cut from release-branch.go1.7 at the revision tagged go1.7rc6. >> >> Please help us by testing your Go programs with the release, and >> report any problems using the issue tracker: >> https://golang.org/issue/new >> >> You can download binary and source distributions from the usual place: >> >> https://golang.org/dl/#go1.7rc6 >> >> To find out what has changed in Go 1.7, read the draft release notes: >> https://tip.golang.org/doc/go1.7 >> >> Documentation for Go 1.7 is available at: >> https://tip.golang.org/ >> >> A comprehensive list of changes since rc5 is here: >> https://github.com/golang/go/compare/go1.7rc5...go1.7rc6 >> >> We plan to issue Go 1.7 in a week's time (August 15). >> >> Cheers, >> Chris >> > -- 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.
[go-nuts] Re: msan failures in Go 1.7 Release Candidate 6
go env GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/root/SQstuff/Code" GORACE="" GOROOT="/root/SQstuff/go1.7rc6clang" GOTOOLDIR="/root/SQstuff/go1.7rc6clang/pkg/tool/linux_amd64" CC="/usr/bin/clang" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build010300364=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" I noticed the residue CXX pointing to g++ so it should be built using this instead: CC=/usr/bin/clang CXX=/usr/bin/clang++ GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./make.bash On Thursday, August 11, 2016 at 11:30:54 AM UTC-4, David Marceau wrote: > > > On ArchLinux with a previously gcc built go binary in go1.7rc5: > Linux blah 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 > x86_64 GNU/Linux > with the latest: > llvm llvm-libs lldb clang clang-tools-extra > > go env > GOARCH="amd64" > GOBIN="" > GOEXE="" > GOHOSTARCH="amd64" > GOHOSTOS="linux" > GOOS="linux" > GOPATH="/root/SQstuff/Code" > GORACE="" > GOROOT="/root/SQstuff/go1.7rc5" > GOTOOLDIR="/root/SQstuff/go1.7rc5/pkg/tool/linux_amd64" > CC="gcc" > GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 > -fdebug-prefix-map=/tmp/go-build292116724=/tmp/go-build > -gno-record-gcc-switches" > CXX="g++" > CGO_ENABLED="1" > > THEN DOING THIS WITH go1.7rc6: > CC=/usr/bin/clang GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./make.bash > It compiles and builds ok. > > I needed that CC in there because it was confused as to what CC it should > be using since I had both gcc and clang installed on my box. > > On Wednesday, August 10, 2016 at 1:07:50 PM UTC-4, Ian Lance Taylor wrote: >> >> On Wed, Aug 10, 2016 at 7:00 AM, David Marceau >> <uticdmar...@gmail.com> wrote: >> > when I install from sources straight from git checkout go1.7rc6 >> > go1.7rc6 FAILS on Asus Z97-A-USB31 motherboard with intel i5-4590, >> > "../misc/cgo/testsanitizers" >> > it core dumps and doesn't give me the success message to start using it >> as >> > the previous go1.7rc[1-4] did. >> > signal: segmentation fault (core dumped) >> > FAIL: msan >> > FAIL: msan2 >> > FAIL: msan3 >> > FAIL: msan4 >> > ... FAILED >> >> Could be https://golang.org/issue/16636, which boils down to: clang >> -fsanitize=memory doesn't work on some systems. This almost certainly >> has nothing to do with the motherboard or processor, but more likely >> has something to do with the kernel version and the clang version. >> >> Ian >> > -- 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.
[go-nuts] Re: msan failures in Go 1.7 Release Candidate 6
On ArchLinux with a previously gcc built go binary in go1.7rc5: Linux blah 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64 GNU/Linux with the latest: llvm llvm-libs lldb clang clang-tools-extra go env GOARCH="amd64" GOBIN="" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/root/SQstuff/Code" GORACE="" GOROOT="/root/SQstuff/go1.7rc5" GOTOOLDIR="/root/SQstuff/go1.7rc5/pkg/tool/linux_amd64" CC="gcc" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build292116724=/tmp/go-build -gno-record-gcc-switches" CXX="g++" CGO_ENABLED="1" THEN DOING THIS WITH go1.7rc6: CC=/usr/bin/clang GOROOT_BOOTSTRAP=/root/SQstuff/go1.7rc5 ./make.bash It compiles and builds ok. I needed that CC in there because it was confused as to what CC it should be using since I had both gcc and clang installed on my box. On Wednesday, August 10, 2016 at 1:07:50 PM UTC-4, Ian Lance Taylor wrote: > > On Wed, Aug 10, 2016 at 7:00 AM, David Marceau > <uticdmar...@gmail.com > wrote: > > when I install from sources straight from git checkout go1.7rc6 > > go1.7rc6 FAILS on Asus Z97-A-USB31 motherboard with intel i5-4590, > > "../misc/cgo/testsanitizers" > > it core dumps and doesn't give me the success message to start using it > as > > the previous go1.7rc[1-4] did. > > signal: segmentation fault (core dumped) > > FAIL: msan > > FAIL: msan2 > > FAIL: msan3 > > FAIL: msan4 > > ... FAILED > > Could be https://golang.org/issue/16636, which boils down to: clang > -fsanitize=memory doesn't work on some systems. This almost certainly > has nothing to do with the motherboard or processor, but more likely > has something to do with the kernel version and the clang version. > > Ian > -- 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.
[go-nuts] Re: Go 1.7 Release Candidate 6 is released
when I install from sources straight from git checkout go1.7rc6 go1.7rc6 FAILS on Asus Z97-A-USB31 motherboard with intel i5-4590, "../misc/cgo/testsanitizers" it core dumps and doesn't give me the success message to start using it as the previous go1.7rc[1-4] did. signal: segmentation fault (core dumped) FAIL: msan FAIL: msan2 FAIL: msan3 FAIL: msan4 ... FAILED To contrast this, Go1.7rc6 does succeed on another much older motherboard Dell Inc. Vostro 430/054KM3, BIOS 2.2.0. On Monday, August 8, 2016 at 4:44:40 PM UTC-4, Chris Broadfoot wrote: > > Hello gophers, > > We have just released go1.7rc6, a release candidate for Go 1.7. > Some say that it's the best one yet. > It is cut from release-branch.go1.7 at the revision tagged go1.7rc6. > > Please help us by testing your Go programs with the release, and > report any problems using the issue tracker: > https://golang.org/issue/new > > You can download binary and source distributions from the usual place: > https://golang.org/dl/#go1.7rc6 > > To find out what has changed in Go 1.7, read the draft release notes: > https://tip.golang.org/doc/go1.7 > > Documentation for Go 1.7 is available at: > https://tip.golang.org/ > > A comprehensive list of changes since rc5 is here: > https://github.com/golang/go/compare/go1.7rc5...go1.7rc6 > > We plan to issue Go 1.7 in a week's time (August 15). > > Cheers, > Chris > -- 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.
[go-nuts] Re: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?
I get what you're saying. I did something similar, but modifying all those
structures places you at risk of changing the entire default specified
behaviour of the ListenAndServeTLS because you now not only introduced the
limitConnections integer, but you in fact brought in other
variables/functions that should have never been changed re-introduced in
the first place.
I want to thank you for providing what you did. It is still very useful.
That said I was hoping for something more deeply integrated within the
current golang compiler itself like the following:
git diff
diff --git a/src/net/http/server.go b/src/net/http/server.go
index 89574a8..f135b57 100644
--- a/src/net/http/server.go
+++ b/src/net/http/server.go
@@ -29,6 +29,7 @@ import (
"time"
"golang_org/x/net/lex/httplex"
+ "golang_org/x/net/netutil"
)
// Errors used by the HTTP server.
@@ -2747,3 +2748,40 @@ func strSliceContains(ss []string, s string) bool {
}
return false
}
+
+func (srv *Server) LimitListenAndServeTLS(certFile string, keyFile string,
maxListeners int) error {
+ addr := srv.Addr
+ if addr == "" {
+ addr = ":https"
+ }
+
+ // Setup HTTP/2 before srv.Serve, to initialize srv.TLSConfig
+ // before we clone it and create the TLS Listener.
+ if err := srv.setupHTTP2_ListenAndServeTLS(); err != nil {
+ return err
+ }
+
+ config := cloneTLSConfig(srv.TLSConfig)
+ if !strSliceContains(config.NextProtos, "http/1.1") {
+ config.NextProtos = append(config.NextProtos, "http/1.1")
+ }
+
+ configHasCert := len(config.Certificates) > 0 ||
config.GetCertificate != nil
+ if !configHasCert || certFile != "" || keyFile != "" {
+ var err error
+ config.Certificates = make([]tls.Certificate, 1)
+ config.Certificates[0], err = tls.LoadX509KeyPair(certFile,
keyFile)
+ if err != nil {
+ return err
+ }
+ }
+
+ ln, err := net.Listen("tcp", addr)
+ if err != nil {
+ return err
+ }
+
+ tlsListener :=
tls.NewListener(tcpKeepAliveListener{ln.(*net.TCPListener)}, config)
+ tlsListener = netutil.LimitListener(tlsListener, maxListeners)
+ return srv.Serve(tlsListener)
+}
On Thursday, August 4, 2016 at 10:45:54 AM UTC-4, Nathan Kerr wrote:
>
> I managed to expand ListenAndServeTLS and then apply LimitedListener.
>
> My code and process are posted at
> https://pocketgophers.com/limit-https-listener/
>
> tcpKeepAliveListener ended up being the only code that was copied but not
> specialized. It would have been nice if it were exported from the http
> package.
>
> On Thursday, August 4, 2016 at 12:27:18 AM UTC+2, David Marceau wrote:
>>
>> I tried just what you mentioned. Unfortunately even my interim solution
>> when it is outside of the net.http package and within mine, there are many
>> services that are not exported meaning I can't use them at all and the
>> variables themselves are inaccessible.
>> I tried copying pasting some functions and tweaking them and I ended up
>> going down a rabbit hole never to get out of. The only way to achieve what
>> I want would be to tweak the original golang sources for
>> net.http.ListenAndServeTLS and stuff surrounding it.
>>
>>
>> On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote:
>>>
>>> Your research revealed the essential lines from ListenAndServeTLS that
>>> basically say:
>>>
>>> 1. create a tls listener
>>> 2. have the server serve using that listener
>>>
>>> The LimitListener example follows this same pattern, just with
>>> net.Listener instead of a tls.Listener. A careful reading reveals that
>>> ListenAndServeTLS does not do anything to http.Server that you cannot do
>>> from outside the http package. This means that you can implement it in your
>>> own code; changing it to fit your needs. Your code will probably flow
>>> something like:
>>>
>>> 1. get a listener
>>> 2. limit that listener
>>> 3. create a tls.Config
>>> 4. tlslistener on LimitedListener with config
>>> 5. Server.Serve(tlsListener)
>>>
>>> I am not sure if it would be better to limit before or after the tls
>>> listener.
>>>
>>> I call this trick expanding convenience functions and explain it in
>>> regards to another problem at
>>> http://pocketgophers.com/expanding-convenience-functions/ (
>>> http://pocketgophers.com/expanding-convenienc
[go-nuts] Re: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?
I tried just what you mentioned. Unfortunately even my interim solution when it is outside of the net.http package and within mine, there are many services that are not exported meaning I can't use them at all and the variables themselves are inaccessible. I tried copying pasting some functions and tweaking them and I ended up going down a rabbit hole never to get out of. The only way to achieve what I want would be to tweak the original golang sources for net.http.ListenAndServeTLS and stuff surrounding it. On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote: > > Your research revealed the essential lines from ListenAndServeTLS that > basically say: > > 1. create a tls listener > 2. have the server serve using that listener > > The LimitListener example follows this same pattern, just with > net.Listener instead of a tls.Listener. A careful reading reveals that > ListenAndServeTLS does not do anything to http.Server that you cannot do > from outside the http package. This means that you can implement it in your > own code; changing it to fit your needs. Your code will probably flow > something like: > > 1. get a listener > 2. limit that listener > 3. create a tls.Config > 4. tlslistener on LimitedListener with config > 5. Server.Serve(tlsListener) > > I am not sure if it would be better to limit before or after the tls > listener. > > I call this trick expanding convenience functions and explain it in > regards to another problem at > http://pocketgophers.com/expanding-convenience-functions/ ( > http://pocketgophers.com/expanding-convenience-functions/). > > To answer your other questions: > > I think that tlsListener is not part of the Server structure (so that you > could easily fetch it and limit it) is for two reasons. First, it keeps the > server and the listener separate. There is no fundamental reason that a > single server could not serve on multiple listeners. > > Second, Serve is basically an infinite loop waiting on Listener.Accept. > What would it mean to change the server's listener while it is blocked > accepting a new connection? The old listener would be blocking. If a > connection was never made to it, the new listener would never accept any > connections. > > The API does give the control you need, just not in the way you looked for > it. > > For that last question, controlling connections is usually done as a way > to control the use of some other resource such as cpu, memory, database > access, etc. Managing resources must be done at both the OS and server > level. What needs to be done depends on what the server needs to do, what > hardware it is running on, service level agreements, etc. Sometimes > limiting, sometimes expanding limits, sometime increasing performance. > > Hope this helps. -- 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.
[go-nuts] Re: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?
I perused your blog entry you mentioned. It's very interesting and will come in handy in the future. Thank you. I can appreciate your point of view about accepting the fact that currently listeners are not part of the Server and just proceed to produce code and get it done ASAP. My interim approach will require me to do as you suggested "expand the convenience function" as an entirely different function within my own package. That said, if we: 1)change the Server duck-type's existing ListenAndServeTLS() contents a touch without affecting its API signature 2)add a few new properties to Server's structure 2.1)MaxListenersCount. The global max count of Listener we want. 2.2)MaxListenerPoolsCount. The global max count of ListenerPool we want. 2.3)ListenerPools with the preferred type (ring, array, channel...) 2.4)Each ListenerPool would hold Listeners with the preferred type (ring, array, channel...) 3)When we add a listener to the Server, it would manage the balancing of the listeners across the pools while keeping to the constraints MaxListenersCount and MaxListenerPoolsCount. This would prevent others from having to individually invest effort to "expand the convenience function" on the very same feature request: limiting connections to a tls server. On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote: > > Your research revealed the essential lines from ListenAndServeTLS that > basically say: > > 1. create a tls listener > 2. have the server serve using that listener > > The LimitListener example follows this same pattern, just with > net.Listener instead of a tls.Listener. A careful reading reveals that > ListenAndServeTLS does not do anything to http.Server that you cannot do > from outside the http package. This means that you can implement it in your > own code; changing it to fit your needs. Your code will probably flow > something like: > > 1. get a listener > 2. limit that listener > 3. create a tls.Config > 4. tlslistener on LimitedListener with config > 5. Server.Serve(tlsListener) > > I am not sure if it would be better to limit before or after the tls > listener. > > I call this trick expanding convenience functions and explain it in > regards to another problem at > http://pocketgophers.com/expanding-convenience-functions/ ( > http://pocketgophers.com/expanding-convenience-functions/). > > To answer your other questions: > > I think that tlsListener is not part of the Server structure (so that you > could easily fetch it and limit it) is for two reasons. First, it keeps the > server and the listener separate. There is no fundamental reason that a > single server could not serve on multiple listeners. > > Second, Serve is basically an infinite loop waiting on Listener.Accept. > What would it mean to change the server's listener while it is blocked > accepting a new connection? The old listener would be blocking. If a > connection was never made to it, the new listener would never accept any > connections. > > The API does give the control you need, just not in the way you looked for > it. > > For that last question, controlling connections is usually done as a way > to control the use of some other resource such as cpu, memory, database > access, etc. Managing resources must be done at both the OS and server > level. What needs to be done depends on what the server needs to do, what > hardware it is running on, service level agreements, etc. Sometimes > limiting, sometimes expanding limits, sometime increasing performance. > > Hope this helps. -- 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.
[go-nuts] Re: how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?
Another question: Why wasn't tlsListener placed as part of the Server structure? I think it makes sense to place it there since it is the server that creates and uses it. It also makes sense to expose it to tweak it as some might more control over it and in this case the constraining the number of connections. It seems we may current create as many connections as the operating system can handle, but isn't it more cautious to have something preventive to limit the number of connections within the golang server itself or are you expecting system admins to limit the number of connections at the Operating System Level? -- 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.
[go-nuts] how to apply netutil.LimitListener() to ListenAndServeTLS()'s listener? how to fetch ListenAndServeTLS()'s listener?
I found an example to limit the number of connections for a listener:
import "golang.org/x/net/netutil"//Within net/netutil/listen.go//func
LimitListener(l net.Listener, n int) net.Listener
connectionCount := 2
l, err := net.Listen("tcp", ":8000")if err != nil {
log.Fatalf("Listen: %v", err)
}
defer l.Close()
l = netutil.LimitListener(l, connectionCount)
log.Fatal(http.Serve(l, nil))
BUT I'm not using net.Listen() and http.Serve(). I'm using the
ListenAndServeTLS().
A closer look into ListenAndServeTLS:
func (srv *Server) ListenAndServeTLS(certFile, keyFile string) error
{
...
tlsListener := tls.NewListener(tcpKeepAliveListener{ln.(*net.TCPListener)},
config)
return srv.Serve(tlsListener)
}
How can I fetch the srv's tlsListener and then apply the
netutil.LimitListener()?
ie.
netutil.LimitListener(srv.tlsListener, connectionCount)?
I'm doing my best not to tweak/recompile golang's sources to introduce this
limitlistener feature to a tls server.
I was hoping someone had a trick to avoid that.
Thank you.
David Marceau
--
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.
[go-nuts] Re: can't get Content-Type and Content-Disposition to force browser to display "file->save..." dialog in the web browser
The core problem was:
w.Header().Set("Content-Disposition","attachment;filename=" +
strOutputFileOfJournalctl)
Should actually be:
w.Header().Add("Content-Disposition","attachment;filename=" +
strOutputFileOfJournalctl)
I preferred to put the above line before the serveFile.
That's all. Thanks to everyone who dropped by.
On Friday, June 24, 2016 at 9:44:00 AM UTC-4, David Marceau wrote:
>
> Here is what is in my import. Maybe I should be looking in goji instead
> of net/http?
>
>
> import (
> "fmt"
> "net"
> "time"
> "strconv"
> "strings"
> "os"
> "encoding/json"
> "net/http"
> "crypto/tls"
> "crypto/rand"
> "github.com/gorilla/mux"
> "github.com/goji/httpauth"
> "github.com/zfjagann/golang-ring"
> "github.com/kabukky/httpscerts"
> "reflect"
> "io"
> "io/ioutil"
> "path/filepath"
> "html/template"
> "os/exec"
> )
>
> On Friday, June 24, 2016 at 9:40:29 AM UTC-4, David Marceau wrote:
>>
>> I tried to repeat the same ordering as the iris infrastructure within the
>> function, but it still behaves not as expected. It does not show the
>> file->save... dialog. It shows the file within the browser as a web page.
>>
>> func blah (w http.ResponseWriter, r *http.Request) {
>> strOutputFileOfJournalctl = "journalctlLog.json"
>> w.Header().Set("Content-Type","application/octet-stream") //forces
>> the save as dialog
>>
>> strSomeStringInJsonFormat := "{ Blah: 'blah value' }"
>> myOutput := []byte(strSomeStringInJsonFormat)
>>
>> //ATTEMPT #1
>> //w.Write(myOutput) //displays in web browser page
>> //ATTEMPT #4
>> //w.Header().Set("Content-Disposition","attachment;filename=" +
>> strOutputFileOfJournalctl)
>>
>>
>>
>> //ATTEMPT #3
>> //w.Header().Add("Content-Length", strconv.Itoa( len(myOutput) ) )
>> //w.Write(myOutput) //displays in web browser page
>> //w.Header().Set("Content-Disposition","attachment;filename=" +
>> strOutputFileOfJournalctl)
>>
>>
>>
>> //ATTEMPT #2
>> w.Header().Add("Content-Length", strconv.Itoa(len(myOutput)) )
>> tmpFile, _ := ioutil.TempFile(os.TempDir(), "OurGeneratedCustomLog")
>> defer os.Remove(tmpFile.Name())
>> tmpFile.Write(myOutput)
>> tmpFile.Close()
>> http.ServeFile(w, r, tmpFile.Name())
>> //ATTEMPT #5
>> w.Header().Set("Content-Disposition","attachment;filename=" + "\"" +
>> strOutputFileOfJournalctl + "\"")
>> }
>>
>>
>> On Friday, June 24, 2016 at 7:06:59 AM UTC-4, David Marceau wrote:
>>>
>>> Again, I want to clarify the file does arrive in the browser, but I want
>>> to ensure the "file->save..." dialog appears in the web browser when it
>>> arrives. I found some older code I wrote a couple of years ago that was
>>> behaving as expected:
>>> w.Header().Set("Content-Type", "application/octet-stream")
>>> w.Header().Set("Content-Disposition", "attachment; filename=" +
>>> myBasePdf + ".pdf")
>>> http.ServeFile(w, req, myGenPdfFileName)
>>>
>>>
>>> I acknowledge when I wrote this email I made a typo, but in my code I do
>>> have the Itoa correctly.
>>> w.Header().Set("Content-Length", strconv.Itoa( len(myCmdOutput) ) )
>>> I never used that content-length field because I read somewhere that I
>>> shouldn't.
>>>
>>> Last night I took a look at iris to see how they do it and found:
>>> https://github.com/kataras/iris/blob/master/context.go#L583
>>> err := ctx.ServeFile(filename, false)
>>> if err != nil {
>>> return err
>>> }
>>>
>>> ctx.RequestCtx.Response.Header.Set(contentDisposition, "
>>> attachment;filename="+destinationName)
>>>
>>> I am scratching my head since the header set content-disposition is
>>> happening after the ServeFile which is different from what all the docs and
>>> what I am used to seeing. It seems calling these functions are
>>> order-independant. When does the connection actually send the file over
>>> the connection?
>>>
>>> I believe the Iris send file also provides what I want as expected
>>> behaviour, but I haven't tried it yet.
>>>
>>> On Thursday, June 23, 2016 at 6:15:16 PM UTC-4, Val wrote:
>>>>
>>>> The commented line seems to have typo strconv.Ito
>>>>
>>>> Maybe the typo prevents proper recompilation, and server goes on with
>>>> old code?
>>>>
>>>
--
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.
