Introduction to WebGMO Technology boot camp （新卒研修）の Web 概論講義資料です。 以下の内容の概要を解説しています。 * URI * HTTP * HTML # URL HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
Go 言語のプロファイル機能とネットワークコネクションにまつわるトラブルシューティング
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog インフラエンジニア見習いの森本です。これまで数年ほどサーバーサイドエンジニアとして開発ばかりをしてきた人が最近インフラエンジニアになりました。 3月末に開催された Go Conference 2017 Spring で開発チームの後藤から弊社で開発・運用している AWS S3 互換の分散オブジェクトストレージ Dragon についての発表がありました。 Goでヤフーの分散オブジェクトストレージを作った話 私は Dragon の運用を担うチームに所属しており、本稿ではその業務の中で発生したトラブルシューティングについて紹介したいと思います。 分散オブジェクトストレージ Dragon で発生していた課題 Dragon で gorout
最速最強Webサーバーアーキテクチャ - Qiita
POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
ELBの基本機能とSSLアクセラレータ設定手順 | AWS情報 | Webシステム開発・運用、サーバー・ネットワーク設計から保守まで 雲屋ネットワークにおまかせ
AWSにはELBというLoadBalancerがあります。主な用途としては ・AutoScalingを使用する際に使用する ・単純なLoadBalancer機能 では少しずつではありますが、基本的な機能について説明します。 SSLアクセラレータ機能 SSLアクセラレータを使用すると何がうれしいのかと言うと、サーバの負荷が減ります。 当然ながらサーバで「暗号化」→「複合化」をするよりはELBでやってもらったほうが負荷は格段に減ります。 Cookieによる同一サーバへのアクセス CookieをELBが発行でき、クライアントから受け取ったCookieを元に与えられた秒数の間、同じサーバに同一クライアントからアクセスされます。 AutoScaling機能 ELBも状況に応じてAutoScalingします。 C:\Users\XXXX>nslookup elb-982033531.ap-nor
HTTPクライアントの接続元IPアドレスを知る
ウェブサーバで、クライアントの接続元IPアドレスを見て挙動を変えたいということはよくある。社内からのアクセスだけ特別扱いしたり、携帯電話キャリアのからのアクセスの時だけコンテンツを表示するなど、用途は広い。 普通、このIPアドレスは REMOTE_ADDR という変数名で取得できる。これはもともと、CGI で使われた仕様（http://tools.ietf.org/html/draft-robinson-www-interface-00）であるようだ。Apache の mod_rewrite なら %{REMOTE_ADDR} で、PHP なら $_SERVER[‘REMOTE_ADDR’] で参照できる。 ところがロードバランサやプロキシを間に挟むと、REMOTE_ADDR がロードバランサ等のアドレスになる。この場合、多くのロードバランサ等では HTTP のリクエストヘッダに X-Fo
HTTPSとバックエンドなPlackアプリケーションとPlack::Middleware::ReverseProxyとHTTPヘッダ「X-Forwarded-HTTPS」と | いわぶろ（ろてん）
# in apache2 httpd.conf (RequestHeader set X-Forwarded-HTTPS %{HTTPS}s) $env->{HTTPS} = $env->{'HTTP_X_FORWARDED_HTTPS'} if $env->{'HTTP_X_FORWARDED_HTTPS'}; $env->{HTTPS} = 'ON' if $env->{'HTTP_X_FORWARDED_PROTO'} && $env->{'HTTP_X_FORWARDED_PROTO'} eq 'https'; # Pound $env->{'psgi.url_scheme'} = 'https' if $env->{HTTPS} && uc $env->{HTTPS} eq 'ON'; server { listen 443; server_name momoco.local;
セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい
WebAPIドキュメント作成サービス「Apiary」を使ってWebアプリ開発を高速化しよう | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
はじめまして。去年の9月にLIGにジョインしましたフロントエンドエンジニアの稲葉です。最近のマイブームは日本酒です。（お酒は弱いです） 去年の11月くらいからずっとAngularJSにどっぷり浸かっていますが、BackboneJSの方が好きです。 今回は、APIのモックサーバを提供するサービス「Apiary」をご紹介したいと思います。実際の案件でRESTfulなアプリケーションを開発する際、とても便利でした！ Apiaryとは http://apiary.io/ 「API Blueprint」と呼ばれるMarkdownを拡張した言語で、APIのインターフェース仕様書を記述すると、その記述をもとにドキュメントの生成とAPIのモックサーバを同時に用意をしてくれるWebサービスです。 モックサーバを準備する まずはとにかく実際に使ってみましょう！ ログイン まずはログインをします。 IDとPas
curl がすごく便利
名前は聞いた事があるけれど、使った事がなかったコマンド。 （いまさらだけど）Webアプリケーションの脆弱性チェックなどで、すごく便利だと実感。 チェックしたいWebアプリケーションにPOSTリクエストを色々変えながら、レスポンスを確認したいときに Paros のようなProxyを使うけれど、curl だとコマンドラインで操作できるので、ターミナル上でも手軽に実行できるし、同じことを繰り返す場合も便利。 ログイン画面などで、テストする場合はこんな感じ。 $ curl http://foo.co.jp/login -c cookie.txt セッションIDがCookieに保存される場合は、一度ログインページを表示してCookieの内容をファイルに保存。 $ curl -v http://foo.co.jp/login \ -d username=guest -d password=guest
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
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
HTTPメソッドのPOSTとPUTの使い分け - アインシュタインの電話番号
どこで見たか忘れたけど、POSTはURLが変わる場合に使用して、PUTはURLが変わらない場合に使用する、と書かれたページを読んだことがあって、POSTとPUTの使い分けはそうするものだと思ってた。が、これは間違い^1っぽい。Webアプリ制作におけるバイブルとも言えるWebを支える技術を読み返していたら、これらの使い分けの指針が載っていて、それは自分が覚えてた使い方と逆だった。 POSTとPUTを使い分ける指針 POSTとPUTを使い分けるのに明確な答えはないみたいだけど、Webを支える技術では以下のような設計上の指針を紹介されていた。 これには正解は存在しませんが、設計上の指針として次の事実があります。 POSTでリソースを作成する場合、クライアントはリソースのURIを指定できません。URIの決定権はサーバ側にあります。逆にPUTでリソースを作成する場合、リソースのURIはクライアントが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Welcome to m-bsys.com
GitHub - httpie/cli: 🥧 HTTPie CLI — modern, user-friendly command-line HTTP client for the API era. JSON support, colors, sessions, downloads, plugins & more.
barlog » ||||« - 2005 Year-End Google Zeitgeist