Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
[B! http] hidex7777のブックマーク
[go: Go Back, main page]

タグ

httpに関するhidex7777のブックマーク (8)

  • 最近、httpstat なるものが流行っているらしい - tellme.tokyo

    github.com おそらく先行実装は python で書かれたこれです。 curl にはウェブサイトの応答時間を計測する機能が搭載されており、このツールではそれを利用して出力結果をグラフィカルに表示させています。単なる curl のラッパーのようなツールなのですが、見た目がリッチになるのに加えて、単一ファイルで実行でき python のバージョンに影響されないような工夫がされているのが、受けているポイントのような気がします。 このツールを見たとき「Go で書いてみるの良さそう!(この手のツールで単一バイナリになるのは嬉しいですよね)」と思い、休憩時間やお昼休みなどにちまちま書いていたら、二日前に先を越されてしまいました(そりゃそうですよね。なんでもスピードが大事だと痛感)。 github.com また、ついこの間まで 800 Stars くらいだったのですが、ここ1週間で爆発的に伸びて

    最近、httpstat なるものが流行っているらしい - tellme.tokyo
  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ?のメモ - 小野マトペの納豆ペペロンチーノ日記

    Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし

    RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ?のメモ - 小野マトペの納豆ペペロンチーノ日記
  • H2O - the optimized HTTP server

    The document describes H2O, an optimized HTTP server developed by Dena Co., Ltd., highlighting its key features such as support for HTTP/1.x and HTTP/2, modular design, and high performance based on efficient memory management and input parsing. It emphasizes the server's capabilities in handling various protocols, its testing methodologies, and design principles aimed at achieving speed and relia

    H2O - the optimized HTTP server
  • Private Presentation

    Looks like this one's off the shelfThe presentation you're looking for was made private. But your next lightbulb moment might be one click away. Search top insights from every field.Explore by category instead

  • あなたにWebSocketは必要ないかも | POSTD

    (訳注:2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus (異なるリアルタイムフレームワーク間での通信を可能とするラッパー)を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション(もしくはWebSocketライクな抽象化レイヤ)の大部分

    あなたにWebSocketは必要ないかも | POSTD
  • HerokuのAPIデザイン

    Herokuが自ら実践しているAPIデザインガイドをGithubに公開した. “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて,ビジネスロジックに集中すること目的としている.Heroku特有なものではなく,一般にも十分適用できる知見となっている. 最近は,モバイル向けにAPIをつくることも多いため,勉強もかねて抄訳した.なお内容は,HTTP+JSONのAPIについて基的な知識があることが前提となっている. 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと.例えば,“成功"を示すステータスコードは以下に従う. 200: GETやDELETE,PATCHリクエストが成功し,同時に処理が完了した場合 201: POSTリクエストが成功し,同時に処理が完了した場合 202: POSTやDELETE,PATCHリク

  • なぜ html の form は PUT / DELETE をサポートしないのか?

    なんで html の from は PUT / DELETE ができないのか、「セキュリティ的理由」とか「歴史的経緯」とか、わかったような分からないような説明はよく聞くけど、実際なんでなのか調べてたら色々教えてもらった話。 ここまでわかったことを blog にまとめました。 / “なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin’ Codes” http://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete

    なぜ html の form は PUT / DELETE をサポートしないのか?
  • 1