ψ(プサイ)さきゅばす2のバグ対処で知ったお話です。HTTPの基礎知識はあることを前提にします。きゅばす2では、公式動画のDLがどうしても出来ませんでした。こんなエラーが出ちゃうんです。allowedどうやらリダイレクションの段階で問題が発生してるみたいですねぇ。くじHTTPでのリダイレクションLocationヘッダは絶対パスしか認められない。LocationHTTPでのリダイレクションとあるページにアクセスした時に他のページにジャンプしなおさせる「リダイレクション」ですが、このリダレクションはHTTPはレスポンスヘッダで301,302,303,307のレスポンスコードを返した上で、Locationヘッダを設定することで実現しています。http://www.google.com/こういうふうなヘッダを返すと、そのページにアクセスした人がGoogleに無条件で飛ばされるわけですね。ジャンプするようになっていました。うーん、特に問題なさそう。Locationヘッダは絶対パスしか認められない。...ところがどっこい、実はLocationヘッダのURLは絶対パスしか認められないのです。)ということで、URIスキーム(httpとかftpとか)から始まる絶対URIであることがわかります。いえ、色々調べてみると、携帯とか一部のブラウザを除くと大体相対パスでも動くそうで、絶対URIを作成時に予測するのが難しい、他人に配布するスクリプトなどでは相対パスで指定していることが多いそうです。動画の場合は絶対URIでも良いと思うのですが今回は相対パスで指定されていて、ふつうのブラウザなどではこれで意図通りに動くのですが、さきゅばす2のPythonでは最近のバージョンまで相対パスに対応していなかったため問題になったようです。最新のバージョンでは相対パスに対応しているので、配布バイナリを最新バージョンに差し替えることにしました。ほかのヘッダではどうなってるの?HTTPのヘッダには、ほかにもいくつかパスを指定できるものがありましたよね。いくつか調べてみました。HTTP/1.1みたいな形式で指定されるときの、あのURIです。authorityなんと...。実は絶対URI指定でも良いのですね。絶対URIでのリクエストがこのサーバに飛んでくるのですが、てっきり不正なリクエストなんだと思ってました。...とはいえ、ほとんどのクライアントは絶対パスで取得するのがふつうなので、ちょっと警戒すべきだとは思いますけど...。Content-Location:Locationと似てますが別物です。リクエストされたコンテンツが別のところからも取得可能な時に使われる...そうですが、実際使われてるのを見たことがありません...。)こっちは相対URIも可能です。同じサーバであることが自然だからなのかなあ。Refererリファラです。)なんと!これも相対URIはOKでした。いえ、世の中のクライアントは大体絶対URIじゃないでしょうか?以上です。RFC読んでみると意外な発見がいろいろありますね。追記:RFC7321では相対URLが認められているその後2012に出たRFC7231では相対URLもOKになりました。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。それ故に...悔いの残らぬよう、やり遂げなさい。