タグ

関連タグで絞り込む (33)

タグの絞り込みを解除

HTTPに関するtyruのブックマーク (39)

  • 先輩と覚える HTTP ステータスコード


    gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩﹁あ、先輩！お願いが！﹂ アプリケーション先輩﹁おー、聞いてやる。詳しく話せ﹂ 101 Switching Protocols 後輩﹁せんぱーい、お願いなんですけどー﹂ アプリケーション先輩﹁ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
    先輩と覚える HTTP ステータスコード
    tyru
    tyru 2017/09/08
    リンク

  • net/http: remove support for status code 418 I'm a Teapot · Issue #21326 · golang/go

    Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account

    net/http: remove support for status code 418 I'm a Teapot · Issue #21326 · golang/go
    tyru
    tyru 2017/09/07
    あれ、Go の net/http で 418 I'm a Teapot 実装されちゃってるじゃん、と思ったらやっぱり issue あった
    リンク

  • HTTP1.1のLocationヘッダは、絶対URLでないとRFC違反 | 月と燃素と、ひと匙の砂糖


    さきゅばす2のバグ対処で知ったお話です。とりあえず、HTTPの基礎知識はあることを前提にします。 さきゅばす2では、公式動画のDLがどうしても出来ませんでした。こんなエラーが出ちゃうんです。 [E][ PyBridgeImpl] Python says: (略) HTTPError: HTTP Error 302: Found - Redirection to url '/watch/1339405721' is not allowed どうやらリダイレクションの段階で問題が発生してるみたいですねぇ。 HTTPでのリダイレクション とあるページにアクセスした時に他のページにジャンプしなおさせる﹁リダイレクション﹂ですが、このリダレクションはHTTPはレスポンスヘッダで301,302,303,307のレスポンスコードを返した上で、Locationヘッダを設定することで実現しています。 どこか
    tyru
    tyru 2017/08/30
    RFC2396 だと絶対 URL じゃないとダメだけど RFC7321 では相対 URL が認められるようになった
    リンク

  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様


    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための︵レスポンスボディに載せられる︶標準的な形式が、RFC7807 Problem Details for HTTP APIsで定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
    tyru
    tyru 2017/01/13
    リンク

  • HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io


    Intro これは、 http2 Advent Calendar 2016 の16日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
    HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io

  • Varyヘッダについてメモ - rougeref’s diary

    ここ最近キャッシュコントロールのヘッダについて研究中。というよりキャッシュってどうやって見つけるんだろうってことでお勉強、実験中です。 Varyヘッダの働きかたについてちょっと誤解していたので忘れないうちにメモ。 Squidの文書によると、2.6あたりからVaryとEtagの両ヘッダをサポートしたとのこと。 で、その文書にはいままでURIだけをキーにしてキャッシュを作成していたが、VaryとEtagのサポートに伴い、これらヘッダ値＋URIでmd5ハッシュを作成してそれをキーにしたと。store.logに残るのがそのmd5値。store.logの5カラム目ですね。 1444184896.876 SWAPOUT 00 0000B6C0 D05226074A35B354673E44DE98357310 200 1444184891 -1 -1 text/html 143485/143485 GE

    Varyヘッダについてメモ - rougeref’s diary
    tyru
    tyru 2016/10/09
    「同一URIならばVaryやEtagをつけたり付けなかったりすると面倒ことになる」Squid の仕様か HTTP の仕様か分かってないけど覚えておこ
    リンク

  • RESTful API設計におけるHTTPステータスコードの指針 - Qiita


    RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK‥最も一般的 304 Not Modified‥条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？︵POSTのキャッシュは一般的ではない︶ 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict‥作成しよ
    RESTful API設計におけるHTTPステータスコードの指針 - Qiita
    tyru
    tyru 2016/09/24
    リンク

  • https://clojure-liberator.github.io/liberator/assets/img/decision-graph.svg

    tyru
    tyru 2016/09/24
    HTTP status code の指針となるディシジョンツリー
    リンク

  • レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016


    私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで﹁H2O﹂というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 本日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず﹁サーバ負荷﹂です。小規模なWebサイトではサーバ負荷はそれほど問題にはな
    レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016

  • google-http-java-client 入門 - ひだまりソケットは壊れない

    Java で HTTP 通信するときのクライアントライブラリを何にするかいつも悩むのですが、最近 google-http-java-client が気になってたのでちょっと使ってみました。 汎用的に HTTP 通信ができればよい、というような用途にはちょうど良さそうです。 数年前からベータ版や RC 版としては存在していましたが、正式にリリースされたのは今年のようです。 google-http-java-client について プロジェクトホーム: google-http-java-client - Google HTTP Client Library for Java - Google Project Hosting Google によって書かれた Java の HTTP クライアントライブラリです。 HTTP トランスポートの抽象化がされており、実際の HTTP 通信を行う低層のライブ

    google-http-java-client 入門 - ひだまりソケットは壊れない

  • なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes

    注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT

  • なぜ 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 をサポートしないのか？
    tyru
    tyru 2014/03/24
    つい最近気になってた／ちなみに某I製Web FWはリクエストをJSで無理矢理全部POSTにしてURLじゃなくJavaクラスにダイレクトに処理を委譲してた。PRG対応等も含めてスキルレベルがバラバラなエンプラではありだと思った。
    リンク

  • 新たなHTTPステータスコード「308」とは？

    By Eva Ekeblad ネットでさまざまなウェブサイトをめぐっていると、「404 Not Found」や「503 Service Unavailable」などの表示を目にしたことがある人も多いはず。この3桁の数字とメッセージの組み合わせは「HTTPステータスコード」と呼ばれ、インターネット技術の最も基本的な仕組みの一部です。1990年代初めに最初の骨組みが作られた仕組みですが、新たに「308 Permanent Redirect(恒久的リダイレクト)」というコードが追加されようとしています。 Pushing the Web Forward with HTTP/308 - IEInternals - Site Home - MSDN Blogs http://blogs.msdn.com/b/ieinternals/archive/2012/03/29/http-308-permane

    新たなHTTPステータスコード「308」とは？
    tyru
    tyru 2014/02/20
    リンク

  • Ruby の http ライブラリの通信を表示する http-dump を作った - 2nd life (移転しました)

    Ruby 上で http を叩いた通信見たい時に、毎回同じ事をやってるので抽象化して http-dump というライブラリを作った。 https://github.com/hotchpotch/http-dump $ gem install http-dump require 'net/http' require 'uri' require 'http-dump' HTTPDump.dump { Net::HTTP.get(URI('http://example.com')) } と http でやりとりしてるコードを block で囲むと、以下のように出力される。 > GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=

    Ruby の http ライブラリの通信を表示する http-dump を作った - 2nd life (移転しました)
    tyru
    tyru 2014/01/11
    リンク

  • FacebookがSPDYを始めました！ - ぼちぼち日記


    1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
    FacebookがSPDYを始めました！ - ぼちぼち日記
    tyru
    tyru 2013/01/27
    ワイルドカード証明書
    リンク

  • Webはインターネットになった - naoyaのはてなダイアリー


    先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については ︻HTTP 2.0の最新動向︼ 第1回‥HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch ︻HTTP 2.0の最新動向︼ 第2回‥HT
    Webはインターネットになった - naoyaのはてなダイアリー

  • どぶお/開発しよう！/git-1 Smart HTTPとgitweb - BioKids Wiki


    gitの環境を整えてみた   最近、バージョン管理システムとして流行のgitを使う環境を整えてみましたので記録。 GitLab 2.0をインストールした記録 -- git-2 GitLabをインストールする リモートリポジトリ   職場からも自宅からもリポジトリにアクセスできるようにしたかったので、リモートリポジトリを作成しました。git + apache2/Smart HTTP   職場のファイアウォールがきつく、HTTPおよびHTTPSしか使えないのでHTTPアクセスを確保することにしました。以前はWebDAVがよく使われていたようですが、その方法だと速度が遅いそうな。それを解決するために用意されたのがSmart HTTPとのことです(たぶん)。 Smart HTTP Transport -- http://progit.org/2010/03/04/smart-http.html
    tyru
    tyru 2013/01/15
    リンク

  • Git - Blog Moved

    Moved! Technical content that was previously found in the blog section of this site has been integrated into the second edition of the Pro Git book.

    tyru
    tyru 2013/01/15
    Smart HTTP Transport
    リンク

  • 次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes


    intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、13年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
    次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
    tyru
    tyru 2012/12/12
    リンク

  • 先輩と覚える HTTP ステータスコード


    gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩﹁あ、先輩！お願いが！﹂ アプリケーション先輩﹁おー、聞いてやる。詳しく話せ﹂ 101 Switching Protocols 後輩﹁せんぱーい、お願いなんですけどー﹂ アプリケーション先輩﹁ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
    先輩と覚える HTTP ステータスコード
    tyru
    tyru 2012/08/24
    リンク
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.