以后會開一個(gè)板塊，摸魚快報(bào)，快速記錄這幾周開發(fā)中雕蟲小技， 也算一個(gè)錯(cuò)題集。

1. 向開發(fā)環(huán)境localhost:3000種植cookie

前端使用Create React App腳手架，默認(rèn)以localhost:3000端口啟動；后端使用golang-gin框架，使用8034端口啟動。登錄模塊走的是sso,前后端分離，后端需要向前端寫入認(rèn)證cookie

c.SetSameSite(http.SameSiteLaxMode)
c.SetCookie("userInfo", userInfoMapString, 60*60*12, "/", cfg.CookieDomain, false, false)
c.SetCookie("access_token", accessToken.(string), 60*60*12, "/", cfg.CookieDomain, false, false)

若種植cookie時(shí)設(shè)置domain=localhost:3000?，實(shí)際會發(fā)現(xiàn)該cookie被種為domain=localhost

① golang給出日志提示：2023/01/12 19:10:48 net/http: invalid Cookie.Domain "localhost:3000"; dropping domain attribute， 該cookie domain屬性被丟棄:

② 瀏覽器認(rèn)定該cookie沒有domain，屬性值被重置當(dāng)前頁面，該Cookie為HostOnly Cookie，后續(xù)請求只有host與cookie的domain完全相等，才能攜帶這個(gè)cookie。

react配置后端地址，要配置為localhost:8034?,而不能是127.0.0.1:8034?

經(jīng)此一役：

• ? 源（Origin）是由 URL 中協(xié)議、主機(jī)名（域名 domain）以及端口共同組成的部分
• ? 本次出現(xiàn)的問題在于兩個(gè)關(guān)鍵cookie屬性 ：

cookie domain：cookie被種植到哪個(gè)域名下？

cookie samesite：請求時(shí)，哪些資源能攜帶該cookie？

2. httpclient timeout報(bào)錯(cuò)經(jīng)驗(yàn)

golang net/http httpclientTimeout:Timeout specifies a time limit for requests made by this Client. The timeout includes connection time, any redirects, and reading the response body. The timer remains running after Get, Head, Post, or Do return and will interrupt reading of the Response.Body.

HttpClient Timeout包括連接、重定向(如果有)、從Response Body讀取的時(shí)間，內(nèi)置定時(shí)器會在Get，Head、Post、Do 方法之后繼續(xù)運(yùn)行，并有能力中斷讀取Response.Body.

如果upstream服務(wù)器處理超時(shí)（upstream_response_time> client設(shè)置的timeout），則會返回context deadline exceeded (Client.Timeout exceeded while awaiting headers)。

如果客戶端使用io.ReadAll讀取body超時(shí)，則會返回context deadline exceeded (Client.Timeout or context cancellation while reading body)。

3. url 大小寫敏感

大家使用net/http 建立的http server，默認(rèn)的請求url path是大小寫敏感的：

s.mux.HandleFunc("/leader", func(w http.ResponseWriter, r *http.Request) {

}

s.mux.HandleFunc("/LEADER", func(w http.ResponseWriter, r *http.Request) {

}

以上會被認(rèn)定為不同的路由path。探究源碼：ServeMux使用?map[string]muxEntry 哈希表來存儲路由。

這與aspnet core的路由行為是不一樣的，/hello、/HELLO都會命中下面的路由。

 app.UseEndpoints(endpoints =>
 {  
    endpoints.MapGet("/hello", async context =>
      {
         await context.Response.WriteAsync("Hello!");
      });
}

w3c官方建議：url大小寫敏感。

URLs in general are case-sensitive (with the exception of machine names). There may be URLs, or parts of URLs, where case doesn't matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive。大意是說：除了?domain主機(jī)名是大小寫不敏感，url一般被認(rèn)為是大小寫敏感。

stackoverflow有更清晰的描述：

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.

4. golang statuscode被作為header，一直很費(fèi)解。

在 Go 語言中，客戶端請求信息都封裝到了Request?對象，但是發(fā)送給客戶端的響應(yīng)并不是 Response 對象，而是ResponseWriter：

func Home(w http.ResponseWriter, r *http.Request)  {
    io.WriteString(w, "Welcome to my blog site")
}

ResponseWriter是處理器用來創(chuàng)建 HTTP 響應(yīng)的接口，其源碼結(jié)構(gòu)如下所示：

type ResponseWriter interface {
   // 用于設(shè)置/獲取所有響應(yīng)頭信息
    Header() Header
   // 用于寫入數(shù)據(jù)到響應(yīng)實(shí)體
    Write([]byte) (int, error)
   // 用于設(shè)置響應(yīng)狀態(tài)碼
    WriteHeader(statusCode int)
}

WriteHeader這個(gè)方法名有點(diǎn)誤導(dǎo)，其實(shí)它并不是用來設(shè)置響應(yīng)頭的，該方法支持傳入一個(gè)整型數(shù)據(jù)用來表示響應(yīng)狀態(tài)碼，如果不調(diào)用該方法的話，默認(rèn)響應(yīng)狀態(tài)碼是 200 OK。

在fasthttp中，設(shè)置請求謂詞：req.Header.SetMethod("POST")， 這種將謂詞作為header的行為，我也是服氣。

只能設(shè)置一次statuscode， 若多次設(shè)置statuscode，以前者優(yōu)先。

例如嘗試以如下方式：

http.NotFound(w, r)   # 會調(diào)用WriteHeader(404)；Write()寫入body
w.WriteHeader(http.StatusInternalServerError)

會產(chǎn)生一個(gè)告警：2023/01/06 19:19:43 http: superfluous response.WriteHeader call from main.ProxyHandler (proxy.go:25), 同時(shí)產(chǎn)生404狀態(tài)碼。

可以采用如下方式清晰定義狀態(tài)碼和body

w.WriteHeader(http.StatusInternalServerError)
fmt.Fprintln(w, "404 page not found")