因爲 RGW 的默認 web server 用的是 civetweb，又因爲 civetweb 的日誌比較簡單，沒法統計用戶通過 S3 讀寫數據的詳細的性能數據，所以就考慮在 RGW 前通過 Nginx 來做本地代理，然後解析 Nginx 的日誌，來獲取請求狀態，數據量和請求的返回時間等信息。
然而一段猛操作之後，發現用戶原來通過 s3cmd 2.0.1 能夠請求成功的請求全都變成403了，因此本地安裝 s3cmd 來測試一下發下還真是 S3Error: 403 (Forbidden)，給 s3cmd 加個 debug 選項 -d，錯誤如下圖。
這裏需要補充一點知識，就是 s3cmd 目前支持兩種認真的方式一種是 v2，一種是 v4，而 s3cmd 2.x 版本默認用的是 v4，而 1.x 版本默認用的是 v2，這兩種認證方式是有區別的，簡單來說就是 v4 除了像 v2，那樣需要S3桶的 accesskey 和 secretkey，還需要如 date 等信息來簽名，然後放到 http request 的 Header 上，而 s3cmd 2.x 版本支持通過在 .s3cfg 配置文件，增加選項 signature_v2 = True 來修改認證方式，所以說，如果想快速解決這個403的問題，讓用戶加上這個選項就可以了。
簽名方式的差別，具體可以參考 AWS 的技術文檔 Create a string to sign for Signature Version 4。
但是爲了不影響用戶原來的使用體驗，不能說平臺方加上了 Nginx 代理之後就讓用戶各種修改，所以通過查閱相關文檔，發現 Nginx 在做代理的時候會將原來請求的 Header 做 buffer 緩存，導致 RGW 接受到的請求的 Header，並不是原來 s3cmd 客戶端發過來的那樣，具體差別可以參考下面 Reference 的資料。所以這個處理起來也比較簡單，只需要給 Nginx 配置文件加上一些特殊的選項就可以了。
proxy_buffering off;
proxy_request_buffering off;
Nginx 代理加上這兩個選項之後，S3Error: 403 (Forbidden) 的問題就解決了。
Reference
- https://github.com/minio/minio/issues/4120
- https://github.com/minio/minio/issues/5571
- https://serverfault.com/questions/732839/cant-connect-to-s3-with-nginx
- https://www.finbourne.com/blog/authenticating-s3-proxy
- https://www.finbourne.com/blog/authenticating-s3-proxy
- https://github.com/s3tools/s3cmd/issues/487
- http://sealblog.com/2018/03/02/rgw-auth/