Several of our users have asked us to include data relative to their account in the HTTP headers of requests we send them, or even responses they get from our API. What is the general convention to add custom HTTP headers, in terms of naming, format... etc. Also, feel free to post any smart usage of these that you stumbled upon on the web; We're trying to implement this using what's best out there
For a web page that exists, but for which a user does not have sufficient privileges (they are not logged in or do not belong to the proper user group), what is the proper HTTP response to serve? 401 Unauthorized? 403 Forbidden? Something else? What I've read on each so far isn't very clear on the difference between the two. What use cases are appropriate for each response?
APIサーバーの仕様を検討している時に、headerに入れる独自パラメータの名前について一悶着(自己完結)あったので、メモ。 何を悩んだのか 例えば、URLには含みたくない secret のようなリクエストパラメータについて、独自にキー名を決めようと思います。 こんな感じ。 で、なんかいい名前ないかなぁと思ってググってたら、こんなやりとりを見つけました。 stackoverflow / Custom HTTP headers : naming conventions On June 2012, the deprecation of recommendation to use the "X-" prefix has become official as RFC 6648. このやり取りの質問とベストアンサーだけ見て「なんだって!独自ヘッダに X- をつけるのは常識じゃないの?時代遅れなの!?
こんにちは、@akase244 です。 Google Chromeさんの常時SSL推奨の動きはいよいよ待ったなしという印象を受けます。 というのも、今年に入ってChromeでフォームが設置してあるSSL未対応ページを開くと「このサイトへの接続は保護されていません」と表示されるようになっていて、非常に不安を煽られるからです。 ということで今回はSSLの話題なんですが、「AWS Certificate Manager」でワイルドカード証明書を発行した際にちょっとつまづいたので、そのときの作業メモです。 SSL証明書のSANフィールドとは そもそも今回ハマった原因は、私がSubject Alternative Names (以下、SAN)を知らなかったことによる問題なのですが、SANというものをご存知でしょうか? SSL証明書にはSAN(サブジェクトの別名)というフィールドがあり、ここにCSRに
ワイルドカードSSLサーバ証明書とは、コモンネームに*.を付ける事で、*.の同一階層部分を無制限に利用できるものです。ひとつの証明書で、指定されたドメイン名に属している同一階層全てのサブドメインが有効に機能します。 通常の証明書は、コモンネームごとに、証明書がそれぞれ必要となりますが、(アルファSSL及びアルファSSLプラスの場合は、デュアルアクセス対応)ワイルドカードの場合は、同一階層の異なるサブドメインで、複数のSSLサーバ証明書を使用せず、1つの証明書でhttpsアクセスで有効にする事が可能となります。 例えば、メールサーバや、FTPサーバ、Webサーバが同一筐体の場合、ワイルドカード証明書を利用することで、1つの証明書で運用することが可能です。 例: ワイルドカード証明書のコモンネーム: *.toritonssl.comの場合 受信メールサーバ: pop.toritonssl.co
ここから少し、楽天モバイルの宣伝になります。 このサイトでアフィリエートや広告を貼るつもりは全然無かったのですが、 6月中に楽天モバイルの契約30件を取るか、船を降りるかするように言われています。 回線の増設を考えている方、お子様に新しく携帯を持たせようと考えている方、 下記リンク先で楽天にログイン後、楽天モバイルの各プランをご検討いただけないでしょうか。 楽天モバイル 紹介リンク このガイドではnginxの簡単な紹介とそれによるいくつかの簡単なタスクを説明します。nginxは既に読者のマシーンにインストールされているとします。そうでなければ、nginxのインストール ページを見てください。このガイドはnginxの開始、停止、設定の再読込みを説明し、nginxが静的コンテンツを提供するように設定する方法、nginxをプロキシサーバとして設定する方法、FastCGIアプリケーションを使って接
トップ コラムGoogleAnalyticsのCookieは、なぜサードパーティCookieではなく、ファーストパーティCookieなのか? ブログをご覧頂いている皆さん、こんにちはニコライです。Nexalではテクニカルエンジニアとして勤めています。技術的な観点から、皆さんの業務にお役立て頂けそうな情報を更新して参ります。今後とも宜しくお願いします。 初投稿のお題は、GoogleAnalyticsのCookieについてです。 公式ヘルプによると、GoogleAnalyticsではアクセス解析の仕組みとしてCookieを利用しており、且つそれはファーストパーティCookieであると謳われています。ただ、これには合点がいかない方も多くおられるようです。「Googleのサーバと通信しているのだから、サードパティではないのか?なぜファーストパーティ?」という疑念があるからです。以下が公式ヘルプの一
最近、Dockerコンテナと仮想化の違いは何?という質問を多くいただくようになりました。今日はこの違いについて技術面とビジネス面から説明をしてみたいと思います。 私は秋刀魚が大好きなので、安いときにスーパーで大量に買って圧力鍋で20分。こういった、汁も含んだお料理の作り置きを保存するのに便利なのがプラスチックの保存容器。これ、実は英語では、Plastic Container と呼びます。 よく、コンテナ技術を説明するときに貨物を運ぶ大きなコンテナの絵を使われる方も多いのですが、個人的にはこちらの秋刀魚を入れたPlastic Containerのほうが、出来ることを語る上ではしっくりきます。 まずは技術面からDockerコンテナと仮想化の違いをできるだけ簡単に説明してみたいと思います。 Dockerコンテナとは?という資料中にこんな絵が使われることがあります。 仮想化との比較です。1個の物理
この連載は カップめんを待つ間に、電車の待ち時間に、歯磨きしている間に“いまさら聞けない”ITトレンドが分かっちゃう! 今さら聞けないITの最新トレンドやビジネス戦略を、体系的に整理して分かりやすく解説する連載です。「この用語、案外、分かっているようで分かっていないかも」「IT用語を現場の社員にもっと分かりやすく説明できるようになりたい」――。情シスの皆さんのこんな課題を解決します。 ハードウェアに搭載されているプロセッサやメモリの使用時間を細かく分割し、それぞれをひとまとめにして複数の個別独立したサーバのように機能させるのが「サーバ仮想化」です。こうして作られた見掛け上のサーバを「仮想サーバ」または「仮想マシン」といいます。この仮想マシンを実現するソフトウェアはハイパーバイザーで、VMwareのESXi、LinuxのKVM、MicrosoftのHyper-Vなどがあります。 一方、1つの
BFF(Backends For Frontends)超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由:マイクロサービス/API時代のフロントエンド開発(1)(1/2 ページ) マイクロサービス/API時代のフロントエンド開発に求められる技術の1つBackends For Frontends(BFF)について解説する連載。初回は「超入門」としてBFFの概要や事例を中心に紹介する。 本連載「マイクロサービス/API時代のフロントエンド開発」では、今注目のBackends For Frontends(BFF)について数回にわたって解説します。初回である今回は「超入門」としてBFFの概要や事例を中心に紹介します。第2回はBFFの作り方について、第3回はBFFを使ったフロントエンド開発者主導のマイクロサービス/API化の手順について解説します。 想定読者は、Webア
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
いまさらながら。そして一部妄想系のメモ。 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと。 万を超える接続に対応するプロセスやスレッドを生成するとメモリ上にプロセスやスレッドの管理領域が確保され、使われるメモリサイズもばかにならない。プロセスとスレッドでは差があり、1接続あたり1プロセス生成するほうがメモリやファイルディスクリプタなど使うリソースが大きくなるはず。 プロセス数、スレッド数、ファイルディスクリプタ数などの上限に達してしまうという問題もある。このあたりは実装依存だったり設定を変えれば増やせたりすると思う。数を設定で増やせても、大きくなると探索が遅くなったりして性能に影響する可能性もありうると思う。 第4回で触れましたが、select(2), poll(2)は、管理するディス
簡単に書くよ スワップ(英:swap)とは メモリが足りないときにメモリの中身をハードディスクに移す(ことで実際よりも大きなメモリがある振りをする)機能のこと。 あるいは 2つのものを交換すること です。 順番に見ていきましょう。 まずは メモリが足りないときにメモリの中身をハードディスクに移す機能 のスワップから説明します。 今回、登場するメモリは「パソコンさんが作業するときに使う机」です。 実は、ですね。 プログラムから見たメモリの大きさと実際にコンピュータにくっついているメモリの大きさは違います。 メモリ内のどーでもいい内容をハードディスクに一時的にしまうことで(ハードディスクの一部をメモリっぽく使うことで)、プログラムに対して実際のメモリより大きなメモリがあると錯覚させる技があるのです。 例えば、そうですね。 コンピュータにくっついている実際のメモリが10GBだったとしましょう。
解説 新たにWebサイトを立ち上げたいが、コストなどの事情からWebサーバ・マシンは増やしたくないとき、既存のWebサーバ・マシンにそのWebサイトを追加することになるだろう。つまり単一のサーバ・マシンで複数のWebサイトを運用するということだ。この場合、どのように各Webサイトへのアクセス要求を正しく割り振るかが課題となる。 単純なのは、Webサイトごとに異なるIPアドレスを割り当て、DNSサーバでも各Webサイトのドメイン名を各IPアドレスに名前解決させることで、各Webサイトへのアクセス要求を各IPアドレスに割り振ることだ。しかし、コストなどの事情からサーバ・マシンにIPアドレスを追加できないことも多い。 Webサイトごとに異なるポート番号を割り当てるという方法もある。しかし、デフォルトの80番以外のポートを割り当てたWebサイトの場合、クライアント側では「http://www.ex
When a server allows access via Basic HTTP Authentication, what is the experience expected to be in a web browser? Ignoring the web browser for a moment, here's how to create a Basic Auth request with curl: curl -u myusername:mypassword http://somesite.example But what about in a Web Browser? What I've seen on some websites, is I visit the URL, and then the server returns response code 401. The br
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
はじめに 先日スタック・オーバーフローでこんな質問に回答しました。 webサーバー、アプリケーションサーバー、Rackといった仕様や概念と、WEBrick、Unicorn、Pumaといった実装の関係が頭の中で結びつきません 質問者の方はwebサーバー、アプリケーションサーバー、Rack、Unicorn、Pumaと言った用語や概念の理解がこんがらかっているように見えたので、このあたりをきれいに説明している記事を探していたところ、以下の記事を見つけました。 A web server vs. an app server - Justin Weiss スタック・オーバーフローでは記事の一部を抜粋して「ざっくり翻訳」したのですが、それだけで終わらせるのはもったいない気がしたので、Qiitaには全文を翻訳して載せておこうと思います。 これを読むと、あなたもwebサーバーとアプリケーションサーバーの違い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く