本文详细阐述了在angularjs应用中，当使用自定义请求头（如`authorization`）发起跨域get请求时，go语言后端服务器如何正确处理浏览器发送的cors预检（options）请求。核心问题在于服务器未能显式响应预检请求，导致404错误。教程将提供go服务器的修改方案，确保cors机制正常运作，避免跨域请求失败。
理解CORS与预检请求
跨域资源共享（CORS）是一种安全机制，允许Web应用程序从不同域名的服务器请求受限资源。当浏览器检测到跨域请求时，会根据请求的复杂性采取不同的策略。
简单请求：满足特定条件的GET、HEAD或POST请求，并且只使用安全的首部字段（如Accept、Accept-Language、Content-Language、Content-Type值为application/x-www-form-urlencoded、multipart/form-data或text/plain）。这类请求会直接发送，服务器响应中包含Access-Control-Allow-Origin等CORS头。
非简单请求：如果请求方法不是GET、HEAD、POST，或者使用了非安全的首部字段（例如自定义的Authorization头），或者Content-Type是application/json等，浏览器会先发送一个预检请求（Preflight Request）。
预检请求使用HTTP的OPTIONS方法，其目的是询问服务器是否允许实际的跨域请求。预检请求会携带以下关键头部：
立即学习“go语言免费学习笔记（深入）”；
- Access-Control-Request-Method：指明实际请求将使用的HTTP方法（如GET）。
- Access-Control-Request-Headers：指明实际请求将携带的自定义头部（如Authorization）。
- Origin：指明请求的来源域名。
服务器收到OPTIONS预检请求后，需要响应200 OK，并在响应头中明确告知浏览器允许哪些源、哪些方法、哪些头部，例如：
- Access-Control-Allow-Origin：允许的来源域名。
- Access-Control-Allow-Methods：允许的HTTP方法。
- Access-Control-Allow-Headers：允许的自定义请求头。
- Access-Control-Max-Age：预检请求结果的缓存时间。
如果服务器的预检响应允许了后续的实际请求，浏览器才会发送真正的跨域请求。否则，浏览器将阻止实际请求并抛出CORS错误。
问题诊断：AngularJS与Go服务器的CORS挑战
在给定的场景中，AngularJS客户端使用$http.get发起请求，并添加了自定义的Authorization头部：
$http.get(env.apiURL()+'/banks', {
headers: {
'Authorization': 'Bearer '+localStorageService.get('access_token')
}
})由于存在自定义的Authorization头部，浏览器会先发送一个OPTIONS预检请求。观察到的OPTIONS请求如下：
OPTIONS /banks HTTP/1.1 Host: localhost:8080 ... Access-Control-Request-Method: GET Origin: http://localhost:8081 Access-Control-Request-Headers: accept, authorization ...
然而，Go服务器的响应却是404 Not Found：
HTTP/1.1 404 Not Found Access-Control-Allow-Headers: Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE Access-Control-Allow-Origin: http://localhost:8081 Content-Type: text/plain; charset=utf-8 Date: Mon, 17 Mar 2014 11:05:20 GMT Content-Length: 19
尽管服务器在404响应中包含了正确的CORS头部（如Access-Control-Allow-Headers和Access-Control-Allow-Origin），但404 Not Found的状态码本身就表明服务器未能成功处理该请求。
问题根源在于Go服务器的路由配置：
r := mux.NewRouter()
r.HandleFunc("/banks", RetrieveAllBank).Methods("GET")
http.ListenAndServe(":8080", r)mux.Router只为/banks路径注册了一个GET方法处理器。当OPTIONS请求到达时，mux.Router找不到匹配OPTIONS方法的/banks路由，因此返回404 Not Found。即使在路由之前设置了CORS响应头，404状态码也会导致浏览器认为预检请求失败，从而阻止后续的实际GET请求。
Go服务器端解决方案：显式处理OPTIONS请求
为了解决这个问题，我们需要修改Go服务器，使其能够显式地拦截并处理OPTIONS预检请求。这可以通过创建一个自定义的http.Handler包装器来实现。
首先，定义一个结构体来包装mux.Router：
package main
import (
"fmt"
"github.net/gorilla/mux"
"net/http"
)
// MyServer 结构体包装了 mux.Router
type MyServer struct {
r *mux.Router
}
// ServeHTTP 方法实现了 http.Handler 接口
func (s *MyServer) ServeHTTP(rw http.ResponseWriter, req *http.Request) {
// 1. 设置CORS响应头
// 确保只为允许的源设置CORS头，增强安全性
allowedOrigin := "http://localhost:8081" // 示例：实际应用中应配置
if origin := req.Header.Get("Origin"); origin == allowedOrigin {
rw.Header().Set("Access-Control-Allow-Origin", origin)
rw.Header().Set("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE")
// 确保这里列出了所有客户端可能发送的自定义请求头
rw.Header().Set("Access-Control-Allow-Headers",
"Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization")
rw.Header().Set("Access-Control-Max-Age", "86400") // 缓存预检结果24小时
} else {
// 对于不允许的源，可以选择不设置CORS头或返回错误
// 这里简单演示，实际应用中可能需要更复杂的逻辑
// rw.WriteHeader(http.StatusForbidden)
// return
}
// 2. 拦截并处理OPTIONS预检请求
// 如果是OPTIONS请求，设置好CORS头后直接返回，不进入mux路由
if req.Method == "OPTIONS" {
rw.WriteHeader(http.StatusOK) // 预检请求成功，返回200 OK
return
}
// 3. 对于非OPTIONS请求，交由mux路由器处理
s.r.ServeHTTP(rw, req)
}
// RetrieveAllBank 是处理GET /banks请求的函数
func RetrieveAllBank(rw http.ResponseWriter, req *http.Request) {
// 实际业务逻辑
fmt.Fprintf(rw, "Retrieving all banks data!")
}
func main() {
r := mux.NewRouter()
r.HandleFunc("/banks", RetrieveAllBank).Methods("GET")
// 使用自定义的MyServer包装mux.Router
server := &MyServer{r}
fmt.Println("Server listening on :8080")
http.ListenAndServe(":8080", server) // 监听并使用MyServer
}代码解析：
- MyServer结构体：它包含一个*mux.Router实例，使得我们可以利用mux的路由功能。
-
ServeHTTP方法：这是实现http.Handler接口的关键。所有进入http.ListenAndServe的请求都会首先经过这个方法。
- 设置CORS头部：在请求被路由之前，统一在此处检查Origin头部，并设置Access-Control-Allow-Origin、Access-Control-Allow-Methods和Access-Control-Allow-Headers等CORS相关响应头。这确保了无论请求类型如何，CORS头部都能被正确设置。
- 拦截OPTIONS请求：if req.Method == "OPTIONS"是核心逻辑。一旦检测到是OPTIONS请求，在设置完CORS头部后，立即调用rw.WriteHeader(http.StatusOK)发送200 OK状态码，然后return。这阻止了OPTIONS请求继续被mux.Router处理，避免了404错误。
- 转发其他请求：对于非OPTIONS的请求（如实际的GET请求），则调用s.r.ServeHTTP(rw, req)，将请求交给底层的mux.Router进行正常的路由处理。
- main函数：将mux.Router实例包装到MyServer中，并将其作为参数传递给http.ListenAndServe。
通过上述修改，当浏览器发送OPTIONS预检请求时，Go服务器会正确响应200 OK并包含必要的CORS头部，从而允许浏览器继续发送实际的GET请求。
注意事项与最佳实践
-
CORS中间件：对于更复杂的Go应用，手动实现ServeHTTP可能会变得繁琐。推荐使用成熟的CORS中间件库，例如github.com/rs/cors。这些库提供了更灵活的配置选项，能更好地处理各种CORS场景。
// 示例：使用github.com/rs/cors package main import ( "fmt" "github.com/gorilla/mux" "github.com/rs/cors" // 导入cors库 "net/http" ) func RetrieveAllBank(rw http.ResponseWriter, req *http.Request) { fmt.Fprintf(rw, "Retrieving all banks data!") } func main() { r := mux.NewRouter() r.HandleFunc("/banks", RetrieveAllBank).Methods("GET") // 配置CORS选项 c := cors.New(cors.Options{ AllowedOrigins: []string{"http://localhost:8081"}, // 允许的来源 AllowedMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"}, // 允许的方法 AllowedHeaders: []string{"Accept", "Content-Type", "Authorization"}, // 允许的头部 AllowCredentials: true, // 允许携带认证信息（如cookies, HTTP认证及客户端SSL证明） MaxAge: 86400, // 预检请求结果的缓存时间 }) // 将CORS中间件应用到路由器上 handler := c.Handler(r) fmt.Println("Server listening on :8080") http.ListenAndServe(":8080", handler) } Access-Control-Allow-Headers的完整性：务必确保Access-Control-Allow-Headers中包含了所有客户端可能发送的自定义请求头。如果客户端发送了服务器未明确允许的头部，预检请求仍会失败。
Access-Control-Allow-Origin的安全性：在生产环境中，Access-Control-Allow-Origin应尽可能具体，避免使用*（通配符），以防止潜在的安全漏洞。
HTTP头部大小写：HTTP/1.1协议规定头部名称是大小写不敏感的。浏览器在发送请求头时可能会进行标准化（例如将authorization转换为Authorization）。服务器在解析请求头和设置响应头时，应遵循常见的规范（例如Authorization），但内部处理时通常不应依赖于特定的字母大小写。
总结
当Web应用（如AngularJS）发起带有自定义请求头的跨域请求时，浏览器会首先发送一个OPTIONS预检请求。Go语言后端服务器必须显式地处理这个预检请求，返回200 OK状态码并包含正确的CORS头部信息，才能允许后续的实际请求。通过实现自定义的http.Handler包装器或使用专业的CORS中间件，可以有效地解决Go服务器在处理CORS预检请求时遇到的404 Not Found问题，确保跨域通信的顺畅进行。
