go-ozzo / ozzo-routing

An extremely fast Go (golang) HTTP router that supports regular expression route matching. Comes with full support for building RESTful APIs.
MIT License
455 stars 51 forks source link

Strange error on https with 1503 0100 0202 0a #10

Closed kolkov closed 8 years ago

kolkov commented 8 years ago

I start two servers: http on port 8080 https on port 8088

go func() {
        s := app.C.GetString("WebServer.Domain") + ":" + app.C.GetString("WebServer.PortHTTPS")
        l.Info("Start Serving HTTPS on " + s)
        err := http.ListenAndServeTLS(s, "./ssl/cert.pem", "./ssl/key.pem", nil)
        if err != nil {
            l.Emergency(err.Error())
        }
    }()

    s := app.C.GetString("WebServer.Domain") + ":" + app.C.GetString("WebServer.PortHTTP")
    l.Info("Start Serving HTTP on " + s)
    // Запуск HTTP сервера и редирект всех входящих запросов на HTTPS
    err := http.ListenAndServe(s, http.HandlerFunc(redirectToHttps))
    if err != nil {
        l.Emergency(err.Error())
    }

If i connecting to port 8088 without https begins, Chrome will download a file as follows:

0000000: 1503 0100 0202 0a

What this?

qiangxue commented 8 years ago

No idea. Is this related with the router?

kolkov commented 8 years ago

Yes, It's on Linux. Can you repeat the same on Mac? in-frame.com:8088

l := app.L.GetLogger("app.webserver")
    l.MaxLevel = log.LevelDebug

    r := routing.NewRouter()

    // serves the files under working-dir/web/assets
    r.To("(/.*)?", routing.Static(app.C.GetString("StaticServer.Path")))
    l.Info("Start Serving static files on " + app.C.GetString("StaticServer.Path"))

    r.Use(
        routing.AccessLogger(l.Info),
        routing.TrailingSlashRemover(http.StatusMovedPermanently),
    )

    r.Get("/", site.Index)
        r.Use(routing.NotFoundHandler())

    r.Error(routing.ErrorHandler(nil))

    http.Handle("/", r)

    go func() {
        s := app.C.GetString("WebServer.Domain") + ":" +              app.C.GetString("WebServer.PortHTTPS")
        l.Info("Start Serving HTTPS on " + s)
        err := http.ListenAndServeTLS(s, "./ssl/cert.pem", "./ssl/key.pem", nil)
        if err != nil {
            l.Emergency(err.Error())
        }
    }()

    s := app.C.GetString("WebServer.Domain") + ":" + app.C.GetString("WebServer.PortHTTP")
    l.Info("Start Serving HTTP on " + s)
    // Запуск HTTP сервера и редирект всех входящих запросов на HTTPS
    err := http.ListenAndServe(s, http.HandlerFunc(redirectToHttps))
    if err != nil {
        l.Emergency(err.Error())
    }

func redirectToHttps(w http.ResponseWriter, r *http.Request) {
    // Перенаправляет входящий HTTP запрос.
    c := conf.LoadConfig()
    ad := c.GetString("WebServer.Domain") + ":" + c.GetString("WebServer.PortHTTPS")
    http.Redirect(w, r, "https://" + ad + r.RequestURI,
        http.StatusMovedPermanently)
}
kolkov commented 8 years ago

Maybe it's golang bug like this? https://groups.google.com/forum/?place=forum%2Fgolang-ru&amp%253Bshowsearch=false&amp%253Bshowpopout=false&amp%253Bparenturl=http%3A%2F%2F4gophers.ru%2F#!topic/golang-nuts/MEATuOi_ei4

kolkov commented 8 years ago

No! It's not a golang issue. This code works perfectly!

package main

import (
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, req *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    w.Write([]byte("This is an example server.\n"))
}

func redirectToHttps(w http.ResponseWriter, r *http.Request) {
    // Перенаправляет входящий HTTP запрос.
    http.Redirect(w, r, "https://127.0.0.1:10443",
        http.StatusMovedPermanently)
}

func main() {
    go func(){
        http.HandleFunc("/", handler)
        log.Printf("About to listen on 10443. Go to https://127.0.0.1:10443/")
        err := http.ListenAndServeTLS("in-frame.com:10443", "cert.pem", "key.pem", nil)
        if err != nil {
            log.Fatal(err)
        }
    }()

    err := http.ListenAndServe("127.0.0.1:10442", http.HandlerFunc(redirectToHttps))
    if err != nil {
        log.Fatal(err)
    }
}
kolkov commented 8 years ago

Minimal code sample to represent this issue:

package main

import (
    "net/http"
    "github.com/go-ozzo/ozzo-routing"
    "log"
)

func redirectToHttps(w http.ResponseWriter, r *http.Request) {
    http.Redirect(w, r, "https://in-frame.com:8088",
        http.StatusMovedPermanently)
}

func main() {
    r := routing.NewRouter()

    r.Use(
        routing.AccessLogger(log.Printf),
        routing.TrailingSlashRemover(http.StatusMovedPermanently),
    )

    r.Use(routing.NotFoundHandler())

    r.Error(routing.ErrorHandler(nil))

    http.Handle("/", r)

    go func() {
        err := http.ListenAndServeTLS("in-frame.com:8088", "cert.pem", "key.pem", nil)
        if err != nil {
            log.Fatal(err)
        }
    }()

    // Запуск HTTP сервера и редирект всех входящих запросов на HTTPS
    err := http.ListenAndServe("in-frame.com:8080", http.HandlerFunc(redirectToHttps))
    if err != nil {
        log.Fatal(err)
    }

}
kolkov commented 8 years ago

My experiments gave the result:

http: TLS handshake error from tls: first record does not look like a TLS handshake

It's strange error on several TCP ports if I use 8081-8088 and some else I have this error, but if I using port 10443 I have no errors! ((( can not understand anything... I think I need to call Edward Snowden... most likely it's NSA bug! )))

kolkov commented 8 years ago

It's worked if my url is

in-frame.com:10443

perfectly, but if I call

in-frame.com:10443/about

a have the same error with loading a file like above. I have no any ideas... (

kolkov commented 8 years ago

This is answer from golang-nuts group:

That's a TLS error message, which Chrome is interpreting as an 
HTTP/0.9 download because the server is speaking HTTPS, but the client 
is expecting unencrypted HTTP. 

Specially, it's a fatal, TLS 1.0 alert with value unexpected_message 
(see https://tools.ietf.org/html/rfc5246#section-7.2) 

Cheers 

AGL 

https://groups.google.com/forum/#!topic/golang-nuts/MEATuOi_ei4 If I right understand this is a Chrome bug?

qiangxue commented 8 years ago

Is your issue solved? With the latest code, do you still have this issue?

kolkov commented 8 years ago

No! I think that not ozzo-routing bug, it's Golang or Chrome bug.