先輩と覚える HTTP ステータスコード
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
キャッシュについて整理 - Qiita
キャッシュとは 使用頻度の高いデータを高速な記憶装置に蓄えておくことにより、いちいち低速な装置から読み出す無駄を省いて高速化すること。また、その際に使われる高速な記憶装置や、複製されたデータそのもののこと。 IT用語辞典 Webサイトの表示においては、一度アクセスしたページのデータを特定の場所に保存することで、次回アクセス時の表示を速くし、サーバへの無駄なリクエストを減らせるというメリットがあります。また一口にキャッシュといっても下記の2種類があるので、どちらを指しているのか（あるいは両方か）意識しておきましょう。 ブラウザのキャッシュ：そのパソコンのユーザーが見たページのデータがローカルに溜まっていく。 キャッシュサーバのキャッシュ：不特定多数のユーザーが見たページのデータがネットワーク上に溜まっていく。 キャッシュの制御方法 ✏️ HTTPレスポンスヘッダ で制御 ➡️ Cache-C
フォームよるファイルアップロードの仕様 - Jakarta Commons FileUploadの利用手順
HTMLのフォームを使ったファイルアップロードはRFC1867に従った動作をします。RFC1867は下記に記載があります。 http://www.ietf.org/rfc/rfc1867.txt フォームを使ったファイルアップロードを行った際にサーバ側にどのようなデータが送られてくるのかについて、上記ページによると次のように書かれています。 下記のようなフォームからファイルをアップロードしたとします。この場合、テキストが1つとアップロードするファイルとなりますが、「file1.txt」と「file2.gif」の2つのファイルをアップロードしたとします。 <form action="http://server.dom/cgi/handle" enctype="multipart/form-data" method="post"> What is your name? <input type=
enctype='multipart/form-data'ってなんだ？ - MUGENUP技術ブログ
こんにちは、MUGENUPアルバイトの倉成です。 今回は僕が前々から気になっていた、フォームからファイルを送信するときのおまじないenctype="multipart/form-data"について調べてみたので、得られた知識をまとめて見ようと思います。 また、マルチパートの情報を検索していると、HTMLのフォームだけではなく、メールのマルチパートの情報に当たることも多くありました。 調べてみると、HTMLの仕様と電子メールの仕様が似ているのは、どうやら歴史的な経緯があるようなので、後半ではインターネット成長の歴史についても少しだけ触れてみようと思います。 multipart/form-data: ファイルを送るおまじない それでは、フォームでファイルをアップロードするシチュエーションを考えましょう。 ファイルアップロードをする場合input要素は<input type="file" />を
高機能ホスティングサービスNetlifyについて調べて使ってみた - Qiita
はじめに Netlify Netlifyは静的なサイトを超高速で提供できるWebサービスです。先日210万ドルの出資を受け話題になりました。わずか3ステップでおしゃれなサイトが作成できるとのことです。本記事の前半ではNetlifyの特徴を軽くまとめ、後半は実際にNetlifyを利用してサイトを作成してみます。 Netlifyの特徴 詳細は公式ドキュメントにあります。今回はその中から一部を抜粋して紹介します。 ビルド、デプロイ、ホスティングの全て Netlifyはフロントエンドのビルド、デプロイ、ホスティングの全てを行います。単純な静的サイトのデプロイであれば下記の3行をコマンドラインに打ち込むだけでできます。 また、NetlifyはGitHubリポジトリとリンクし、GitHubリポジトリにプッシュがある度にgruntやgulpを介したビルドをしたうえでサイトをデプロイしてくれます。 これら
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTP（ RFC7230 〜 RFC7235 ）共通ページ
この~pageでは、 ~IETFによる `Hypertext Transfer Protocol（ HTTP ）＠~HTTPWG/$ の 2014年に公表された~versionを成す，次に挙げる仕様に共通な内容を（日本語訳にあたり）集約する ⇒＃ `RFC7230＠~7230$, `RFC7231＠~7231$, `RFC7232＠~7232$, `RFC7233＠~7233$, `RFC7234＠~7234$, `RFC7235＠~7235$ これらは、 今や，2022年 6 月に公表された中核~HTTP仕様（ RFC9110, RFC9111, RFC9112 ）により廃用にされた。 それらの日本語訳は、 `~HTTP日本語訳 共通~page＠~HTTPcommon$にある。 ~HTTPに関係する各種 RFC の（網羅的でない）一覧, および ~HTTP全般に共通な内容（構文の表記法な
Cookie の仕様とセキュリティ | yunabe.jp
このドキュメントの目的は Cookie とは何かを一から説明することではないので、そもそも Cookie とは何で何に使えるのかといった話はWikipedia の Cookie の記事などを参考にして下さい。 ここでは Cookie がどういうものかは大体理解しているという前提で、仕様の確認をしていきます。 目次 Set-Cookie ヘッダを使って Cookie を保存する Cookie を参照する JavaScript を使って Cookie を保存・参照する Cookie の属性 domain 属性 path 属性 max-age と expire secure httponly その他 クッキーと port 番号 Cookie が絡むセキュリティ関係の問題 通信路上でのクッキーの漏洩 クロスサイトスクリプティング (Cross Site Scripting, XSS) Set-Co
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTf
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
Amazon S3で限定したIPアドレスに公開する静的サイトをつくる - CrowdWorks Engineer Blog
Amazon S3のバケット(Bucket)に、アクセス元IPアドレスによるアクセスコントロールをかけられる、ってご存知でしたか？ この記事では、AWSやS3のリクエスト認証の概要と、それを踏まえた「アクセス元IPアドレスによるバケットへのアクセスコントロール」の方法、その応用例を紹介します。 バケットに入れるオブジェクトの機密性によっては、デフォルトの 「認証情報をつける」以外の方法でアクセスコントロールができると便利です。 例えば、機密でもなんでもないファイルや静的サイトを、ロケーション的に同じオフィスにいる人にゆるく共有したい、 くらいの用途であれば、アクセス元IPアドレスが使えることがあります。 実際、弊社でも、このエンジニアブログを公開前にテスト・レビューするために、 アクセス元IPによる読み取り制限をかけたバケットにデプロイしています。 なお、情報セキュリティに関わることなので
技術/HTTP/URLエンコードで 0x20(スペース) を "+" にすべきか "%20" にすべきか - Glamenv-Septzen.net
id: 1170 所有者: msakamoto-sf 作成日: 2013-03-23 22:18:13 カテゴリ: HTML HTTP ネットワーク [ Prev ] [ Next ] [ 技術 ] ※時間がないとか、だらだらとRFCの解説を読んでる暇が無い方は、末尾のまとめ部分だけ目を通していただければ十分かと。 URLのpath中やquery中、POSTリクエストボディ中で、0x20のスペースを、"+"に変換するのが「正しい」のか、"%20"にするのが「正しい」のか、わからなくなってきたのでちょっと調べてみました。 ただしRFCの全文を熟読してるわけではないので、言い回しや表現はもとより理解そのものが間違ってる可能性もあるので、話半分程度に参考にしてください。 "+"を使うべきか、"%20"を使うべきか、よく迷う箇所： URLのパス中 URLのクエリ中 "application/x-w
HTML5 Conferenceレポート - 「HTTP/2の現状とこれから」編 - 株式会社一燈 エンジニアブログ
こんにちは。業務が終わって帰宅している途中にスクフェスのガチャを引いてみたら、なんとURの凛ちゃんを引き当てて気分のいいTickです。前回のエントリからの続きで、今回は「HTTP/2の現状とこれから」のセッションについてレポートしたいと思います。 HTTP/2の現状とこれから from shigeki_ohtsu HTTP/2の現状とこれから - HTML5 Conference - - YouTube 前半はHTTP/1.1の問題点をふり返り、中盤はHTTP/2のつなぎとして使われているSPDYと、HTTP/2の対応状況と最終仕様の一部が紹介されました。最後に、HTTP/3とQUICに関する説明がありました。 Webの基幹技術に関するセッションであり、クライアントサイドの話かというと、そうでもなかったような気がします。しかし、現状のプロトコルは様々な点で問題を抱えており、HTTP/2の仕
モバイルアプリ開発者のための mitmproxy 入門 - Qiita
はじめに モバイルアプリを開発しているときに、アプリとサーバー間の通信を確認したいときがあります。たとえば、期待通りの HTTP リクエストが送られているか調べたり、サーバーからのレスポンスが間違っていないか確認したりする必要が生じます。 そんなときに、いちいちデバッガで止めても良いのですが、プロキシをはさめば簡単に通信を覗くことができます。しかも、レスポンスを改竄して、わざと不正なレスポンスにしてアプリがクラッシュしないかテストしたり、特定のリクエストだけブロックしてサーバー障害を擬似的に再現することができます。 mitmproxy とは mitmproxy は man-in-the-middle 型のプロキシサーバーのツールです。OS X や Windows、Linux 上で動作し、対話式の CUI を持ちます。SSL サポートをしている点が特長になります。 公式サイト: http:/
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
futureshock-ed.com - futureshock ed リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
間違いだらけのWEBサーバ Keep-Alive - 新・浅く広くをモットーに - WEBプログラマ メモ
14:30 | Keep-Alive on / off に関する文献の多くが曖昧であることが気になっていたので、まとめてみました。Apacheのドキュメントから、Keep-Aliveの説明を拝借しますと、HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、複数のリクエストが同じTCPの接続で送られる、長時間持続する HTTP セッションを提供します。つまり、Keep-Aliveは、『TCP 3ウェイハンドシェイクの節約』であるという点を理解しなければなりません。たいていの文献は『画像やCSSが多いサイトでは、接続を使い回すことにより無駄遣いをなくす』という説明をしていますが、この接続を使い回すという表現も曖昧な気がします。何となく分かった気になってしまう人も多いのではないでしょうか。それでは、まずは以下のようなhttpd.confで、Apacheの動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpbin.org
GitHub - typhoeus/typhoeus: Typhoeus wraps libcurl in order to make fast and reliable requests.
