タグ

httpに関するnanakosoのブックマーク (68)

  • 新しいHTTPステータスコード「451」が承認される--検閲による閲覧禁止示す (CNET Japan) - Yahoo!ニュース

    UPDATE 政府がどのウェブサイトをアクセス禁止にしているのかを国民に隠しておくことが、今後は難しくなるだろう。検閲されていることを警告する新しいエラーコードが登場するためだ。 インターネットでは、100番台から500番台までの幅広いステータスコードが利用されている。これらのステータスコードは、サーバのダウンなどの異変が生じたことを知らせるためや、特定のページにアクセスさせないようにするために利用される。皆さんも、ページを見つけられなかったことを知らせる404エラーメッセージをおそらく何度か目にしたことがあるだろう。 しかし、ウェブページのダウンが技術的な問題のためなのか、政府の介入のためなのかを見分けるのは普通、容易ではない。そこで新しい451コードの登場となる。 インターネット技術の標準化組織Internet Engineering Steering Group(IESG)は米

    nanakoso
    nanakoso 2015/12/22
    マジか
  • Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes

    Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ

    Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
  • HaskellでHTTP/2を実装してみました

    1 Haskell HTTP/2 @kazu_yamamoto 2 TLS Warp 3 2009 Haskell HTTP Mighty 2011 Mighty WAI WAI HTTP Warp 2013 10 http/2.0 2013 12 HPACK http2 lib 2014 10 http2 lib 2014 10 Warp http2 2014 11 TLS 4 TLS 5 1 Haskell TLS ALPN(Application Layer Protocol Negotiation) NPN(Next Protocol Negotiation) NPN ALPN ( ) 6 Warp HTTP/2 7 8 HTTP/2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Firefox TLS_ECDHE_RSA_WITH_AES_128_G

  • Twitter や Facebook が SSL 3.0 を無効にしたので死にかけた話 - しばやん雑記

    今朝、Twitter や Facebook が SSL 3.0 を素早く無効化したため、API を使って処理を行っていたアプリが全滅するという悲惨な出来事が発生しました。 Twitter や Facebook の API を使っている場合、Global.asax.cs とかの初期化コードに以下のような設定を書いていると、接続を確立出来ないので死にます。 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 実際に twitter.com へアクセスするコードを書くと、見事に例外が投げられます。 SSL 3.0 は無効化されているので、チャネルを作れないのは当たり前と言えば当たり前です。 ちなみに SecurityProtocolType.Ssl3 以外を指定している場合には成功します。 当然ながら、何も指定してい

    Twitter や Facebook が SSL 3.0 を無効にしたので死にかけた話 - しばやん雑記
  • Content-Disposition によるダウンロードファイル名の指定について - とあるベンチャーのCTOの日記

    Content-Disposition ヘッダーによるダウンロード時のファイル名の指定について、色々調べたことをまとめます。 まずファイル名の指定方法には2種類あり、ブラウザによって対応状況が違います。 - attachment; filename="hogehoge.pdf" - attachment; filename*=uti-8'ja'hogehoge.pdf いずれも RFC 5987 に規定されている書き方に準拠しているので、両方とも正しいです。 IE の場合、IE9 は両方に対応していますが、IE6-8 は前者のみに対応しています。 Chrome (18.0) と Firefox (11.0) は両方に対応しています。Safari (5.1.5) は前者のみで、2バイト文字の取り扱いはできません。 ファイル名はパーセントエンコードする必要があります。パーセントエンコーディング

    Content-Disposition によるダウンロードファイル名の指定について - とあるベンチャーのCTOの日記
  • なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes

    Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか? 何が問題で、なぜ Google はそれらを作り変えるのか? SPDY や QUIC は Google の独自プロトコルだけど、それは当にただの独自プロトコルで終わらせていいのか? 20% ルールで作ってみた Play プロジェクトでしかないのか? こうした新しい動きには、かならず「それまで」と「今」を踏

    なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
  • Loading...

  • URLに含まれる #! の意味を調べた過程メモ | ず@沖縄

    TwitterのURLに #! が含まれることがある。例えば http://twitter.com/#!/zu2 のように。 これが何の意味か気になっていたのだけど、ようやく調べられたのでメモしておく。 (こうやって書いておくと、忘れたときに探しやすい。 我ながら忘れっぽい ^^;) 何の意味か知りたい人へ:末尾に解説してるサイトへのリンクを貼ってありますので、そちらをご参照下さい。 どうやって調べたらいいか素直に #! をgoogle検索に入れても記号は無視されてしまう。 URL “#!" のように “ ”で括っても駄目。この状態で暫く放置してたのだけど、さっき閃いた。 URL “sharp-exclamation" だ。 こういうのは日語なら思いつくけど、英語だとなかなか思いつかない。 この検索から、同じように困ってた人のつぶやきを見つけて芋づる式に情報が得られた。 https://

    URLに含まれる #! の意味を調べた過程メモ | ず@沖縄
  • さらなる「#!」URL批判 - karasuyamatenguの日記

    このブログはlifehackerを含むgawkerメディア系サイトの#!URLへの移行を批判している。 http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/ 以下、isolaniとテングの見解をごっちゃ混ぜに紹介する。 lifehacker他のgawkerメディアサイトが数日前に長時間におよびアクセス不能になった。(厳密に言うとページ内のコンテンツアクセス不能になった) #!URLベースのサイトはJavaScriptにエラーがあるとコンテンツが一切ロードせずのっぺらぼう状態になってしまうようだ。 #!について 「#!」は何で呼ぶの? shebangと綴られる。 Hash=# Bang=!の略 発音すると「シバン」といったところか。(ちなみにUnixの#!とは無関係) 以下「#URL」は: サイト内のロケーション情

    さらなる「#!」URL批判 - karasuyamatenguの日記
  • なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改

    完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復

    なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
  • パーセントエンコーディング - Wikipedia

    パーセントエンコーディング (英: percent-encoding) とは、URIにおいて使用できない文字を使う際に行われるエンコード(一種のエスケープ)の名称である。「%」を使用していることから、この名称で呼ばれている。一般にURLエンコードとも称される。 URLエンコードには、上記のパーセントエンコーディングによる符号化と以下に記述するapplication/x-www-form-urlencodedによる符号化の2種類がある。半角スペースはパーセントエンコーディングでは「%20」に符号化されるが、application/x-www-form-urlencodedによる符号化では「+」に符号化される。 概要[編集] URL Standardでは、URLのパス部分の構文解析の際、以下 (path percent-encode set) に該当する文字であれば、UTF-8で符号化のうえパ

  • ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks

    How browsers work Stay organized with collections Save and categorize content based on your preferences. Preface This comprehensive primer on the internal operations of WebKit and Gecko is the result of much research done by Israeli developer Tali Garsiel. Over a few years, she reviewed all the published data about browser internals and spent a lot of time reading web browser source code. She wrot

    ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks
  • Firefox11リリース!SPDYプロトコルで通信してみよう!

    Firefoxの最新版Firefox11がリリースされました。Firefox11では、主に以下の点が変更されています。 Google Chromeから、ブックマーク、履歴、Cookie をインポート可能に。 Firefox Sync でアドオンを同期できるように。 CSS3 の text-size-adjust プロパティ に対応。 HTML5 動画のメディアコントローラを再設計。 HTML 要素の outerHTML プロパティ に対応。 ソース表示の構文強調表示に HTML5 パーサを採用。 セキュリティ、安全性問題の修正。 また、今回のバージョンからGoogleが策定を進めている新しい通信プロトコルである、SPDY(スピーディ)プロトコルでの通信が可能になっています。SPDYは、HTTPよりも高速に通信することができる、とされています(一つのコネクションで多くのストリームを処理するこ

    Firefox11リリース!SPDYプロトコルで通信してみよう!
  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

    Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係

    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
  • Opera + Togetter.com = 404 ? まとめ - 'ashula.info

    概略 Opera で Togetter.com に繋げられない問題は AWSDNS が最短 60秒で切り替わるのに,Opera が内部でキャッシュしていてドメインを正常に解決できていないことが原因と推定.以下,起きていた現象と調査した内容について記述し,最後にとりあえずの対処法を検討してみる. 対処法まで飛ばす 追記 誤解を招いてもつまらないので,一応補足. AWS ELB では,最低でも1時間は再利用しない ..“)と言っているが TTL (60) がそもそも問題で,その他いくつかの理由で DNS サーバが返してきた TTL をブラウザが意図的に無視するようになっているので (1,2,3 )「Opera が悪い」かどうかは微妙なところ. Firefox の about:config#network.dnsCacheExpiration とか Chromechrome://ne

    nanakoso
    nanakoso 2011/11/25
    [AWS}障害
  • RESTに対する7つの誤解

    海外に行くと、既に REST対SOAPの決着は付いている[1](エンタープライズでもコンシューマでも)ように見えるのだが、日国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。(殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション:RESTの詳細でより詳細に書かれている。) 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか? どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT

    RESTに対する7つの誤解
  • .htaccess ファイルを簡単作成「.htaccess Editor」

    リダイレクト Fromにサイトパスを入力、ToにURLを入力 301 Moved Permanently 恒久的に移動 From: To: From: To: From: To: 302 Moved Temporarily 一時的に移動 From: To: From: To: From: To:

  • ローカルにある画像をtumblrにPOSTするスクリプトを書いた | trash-area.com

    Tumblr のツールをいろいろ探してたのですが どーにも見つけられなかったのがこれ。 「ローカルにある画像を Tumblr に投稿するだけのツール」 基ブラウザで見てる画像やらテキストやらが対象だからでしょうか。 ブラウザ(Firefox)からなら Tombloo というのが最強のような気がしますし、 実際これひとつで全部済んでしまうんですけどね。 ただ、個人的には面白い画像とかテキストは2ちゃんねるのほうがずっと多い気がしていて、 ずーっと2chブラウザから投稿できないのがネックでした。 ということで(ブラウザ以外の)ローカル(キャッシュ)にある画像を Tumblr にダイレクトにポストするスクリプトを書いてみました。 言語は WSH + VBScriptです。 スクリプトから HTTP で multipart/form-data なエンコードで バイナリデータをPOSTするのってな

  • WebSocketがセキュリティ問題を解決して再び実装へ

    Webブラウザとサーバのあいだで専用のプロトコルを用いて通信を行うことで、サーバからのプッシュなど、より柔軟なデータのやりとりをWebブラウザとサーバ間で可能にするWebSocket。当初はHTML5仕様の一部として検討され、その後独立した仕様となりましたが、昨年12月にセキュリティ上の問題が発覚。見直しが行われていました。 WebSocketはプロトコルをIETFが、APIをW3Cが策定中ですが、IETFセキュリティ問題を解決したプロトコル仕様のラストコールを発表しています。いつもWeb標準の動向を伝えてくれる「Web標準Blog」の記事「WebSocketプロトコルがLast Callに」が伝えています。 過去のバージョンとの互換性はなし WebSocketは、昨年にFirefox 4やOperaに実装されましたが、プロトコルにセキュリティの問題が発覚。いったん機能が無効になりました

    WebSocketがセキュリティ問題を解決して再び実装へ
  • Android組込みのHttpComponent(HttpClient)の正しい使い方といくつかのtips - terurouメモ

    ブログ等に掲載されているHttpComponentのサンプルコードは、重要なところが端折られて紹介されている(というか間違っている事を知らずに書いている疑惑すらある)ことが多いので、正しいサンプルコードを書いておく。 まぁ、ここだけでなくApache HttpComponentsのドキュメントもちゃん読みましょう。あ、Androidのリファレンスにはロクに使い方が書いてないので、あんなゴミだけ読んでてもダメですよ。 要点 ポイントは2つ。 ResponseHandlerを使ってコードを書く HttpResponseの内部リソースを自動で解放してくれるので、ミスがなくなり、コードも簡潔になる。ブログ等ではHttpResponseを使わないコードもよく掲載されているが、リソースの解放処理が記述されていないことが多いのであまりよろしくない。 なお、ResponseHandlerを使わずに自分でリ

    Android組込みのHttpComponent(HttpClient)の正しい使い方といくつかのtips - terurouメモ