Reach Over The Sky, Tear The Sky

オリジン間リソース共有 (CORS)という技術があります。 ドメインAのWebページを表示する際に、一部のコンテンツをドメインBから取得してそれを表示したいといった場合に利用する必要があります。 それは最近のWebでは割とありふれたことだと思います。 なので意識せずともかなりの頻度で利用されているのではないでしょうか。  先日業務でCORSを意識した問題に直面してしまったこともあって、一度きちんとした技術文書を読んだ方が良いと思い、Mozillaが提供している MDN web docsの丁寧なドキュメント を読んでみました。 CORSまとめ WebブラウザがドメインAのページを取得したいが、ドメインAのそのページはドメインBのコンテンツを含むといった場合に、ドメインAのサーバはドメインBのコンテンツを取得して自ページのコンテンツの一部としてWebブラウザに返さなければいけない その時に利用される技術がCORS CDNで画像やスタイルシートやフォントやスクリプトを配信している昨今ではかなりの頻度で利用されていると思われる 基本的にはHTTPヘッダに所定の内容をクライアントとサーバが用意することで成り立つ CORSができるかどうかを確認するために「プリフライトリクエスト」という事前HTTPアクセスが必要である 「プリフライトリクエスト」はOPTIONメソッドで行われる…GETやPOSTではない 「プリフライトリクエスト」が発生しない「単純リクエスト」というCORSリクエストもあるが該当条件が厳しい 特に世の中に多そうなcontent-typeが「text/html」のページは単純リクエスト対象外なので基本的にはほとんどのCORSでプリフライトリクエストが発生すると考えた方が良さそう プリフライトリクエスト時にクライアントから発送される「Access-Control-Request-Method」にはプリフライト後の本来のリクエストでどのメソッドが使われるかが書かれている 同様に「Access-Control-Request-Headers」には次に行われる本来のリクエストでどのようなヘッダが送信されるかについて書かれいる プリフライトリクエストを処理するためにサーバ側（CORSで一部コンテンツを提供するドメインBのサーバ）はOPT

自分が送ったコミットを特定のブランチ（今回はstaging）にマージしてくれと言われて対応した時のメモ。 まずこうやってリポジトリを clone して hub am −3 コマンドを使ってマージしようとした。 git clone git@github.com:(team name)/(repository name).git cd (repository name) git checkout staging hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) 認証失敗 そしたら hub am -3 コマンドが認証失敗になりうまく動かない。 $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Error getting pull request: Unauthorized (HTTP 401) Bad credentials 色々調べたけど結論としては ~/.config/hub に書いてある認証情報が古かったので消すと認証の再要求が発生して解消した $ rm ~/.config/hub $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) github.com username: hub am -3 コマンドでマージしようとしたらコンフリクト $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Applying: (this is a comment of commit) Using index info to reconstruct a base tree... M circle.yml Falling back to patching base and 3-way merge... Auto-merging circle.yml CONFLICT (content): Merge con