Couple of weeks ago when I was publishing The Hidden Cost of URL Design I needed to add SQL syntax highlighting. I headed to PrismJS website trying to remember if it should be added as a plugin or what. I was overwhelmed with the amount of options in the download page so I headed back to my code. I checked the file for PrismJS and at the top of the file, I found a comment containing a URL: /* http
このように、Cookie自体はいきなり誰かの個人情報・プライバシーに触れる仕組みではありません。あくまでアクセスを識別するための技術です。また、ECサイトやSNSのように、利用者を識別して動作しなければならないWebサイトではCookieはかならず必要になります。 サードパーティークッキーって？ 今回話題になっているのは、「サードパーティークッキー (3rd Party Cookie)」です。これもCookieの一種なのですが、ここまで出てきたものと少し扱いが異なります。それは、Cookieが複数のWebサイトをまたがって利用されるという点です。 サードパーティーCookieの説明のために、A社のWebサイト、B社のWebサイトという、無関係な二つのWebサイトがある事にしましょう。そして、ここにP社のWebサイトを追加します。P社のWebサイトと書きましたが、ここで想定しているのは、A社
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/content/iss
2022/12/15 追記 手順の変更 以前の記事との違いは、 Argo Tunnelという名前がなくなった cloudflaredの設定にトンネル先を入れていたが、それはCfのWebで入力したものをリアルタイムに反映するようになった。ようするに設定値はトークンだけ。 Tunnelの作成 これで自宅内LANとCfの間のVPN（のようなもの）を確立させる。 ここでインストールする cloudflared が動作していないと公開できないので注意 Cloudflare(以下Cf) のダッシュボードにログイン 左側メニューから Zero Trust をクリック 左側メニューの Access -> Tunnels をクリック 右上、Create a tunnel をクリック トンネルの名前（何でもよい）を入れて次へ cloudflared を動かすための情報が表示されるのでどれかを実行。一番楽なのは
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
Web 開発者は HTTP レスポンスをよく見る。 以前 CDN を導入する際に、キャッシュがヒットしているかどうか、どこのエッジがキャッシュを返しているかを確認するためにヘッダをよく見ていた。また、ヘッダだけではなく、TTFB といったレスポンスタイムも気にしている。とにかく HTTP レスポンスをよく見る。 HTTP レスポンスを確認する３つの方法 Chrome さえあれば DevTools を見て一目瞭然である。 とはいえ、コマンドラインで確認したい時がしばしばある。 GUI を操作するよりも手軽である。 その場合はcurlコマンドを叩けばよい。 これでプロトコル、ステータス、ヘッダが分かる。 また、レスポンスタイムを測りたければ、その名もttfb.shというcurlをラップしたコマンドラインツールがある。 https://github.com/jaygooby/ttfb.sh この
2024/11/22 追記: draft更新が停滞していましたが、著者陣も増え、2024年10月に更新が入り引き続き標準化に向けて作業中です。 新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました
3rd パーティクッキーの廃止計画が世間を賑わせています。一方で、3rdパーティクッキーには、トラッキング目的でないユースケースもあります。それらのために、3rdパーティクッキーの制限を緩和する「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが検討されています。 この仕組みに則っていれば、制限のもと3rdパーティクッキーを使えるようになります。 もちろん、これはトラッキングが出来ないようになっています。 仕様: https://github.com/WICG/CHIPS Chromeの実装計画: 「Intent to Prototype: Cookies Having Independent Partitioned State (CHIPS)」 ユースケースについては、仕様の中で述べられていますのでそちらを参照ください
Most of the time, http://localhost behaves like HTTPS for development purposes. However, there are some special cases, such as custom hostnames or using secure cookies across browsers, where you need to explicitly set up your development site to behave like HTTPS to accurately represent how your site works in production. (If your production website doesn't use HTTPS, make it a priority to switch t
Also see: How to use HTTPS for local development. In this post, statements about localhost are valid for 127.0.0.1 and [::1] as well, since they both describe the local computer address, also called "loopback address". Also, to keep things simple, the port number isn't specified. So when you see http://localhost, read it as http://localhost:{PORT} or http://127.0.0.1:{PORT}. Summary When developin
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。 スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。 やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。 「HTTP Partial POST Replay」では、ユーザの接続
ᕕ( ᐛ )ᕗ こんにちわ、しいたけです。 webのhttps化が推進される昨今ですね? https通信は経路上での通信内容が盗聴・改竄されるのを防ぐことができますが、開発用途でhttps通信の内容を確認したい場合が稀にあります。 そのような場合は mitmproxy などを導入すればよいのですが、せっかくなので実際にこのようなProxyをGoで実装してみて、 中間者攻撃(Man-in-The-Middle Attack)がどのような手法でhttps通信を盗聴・改竄するのか確かめてみました。 実際に書いたProxyのコードはこちらです yuroyoro/mitm_proxy_sample https proxy と HTTP CONNECT tunneling まず、通常のhttps Proxyの動作を確認してみましょう。 httpsでは、ProxyはクライアントからのCONNECTメソッ
メルカリでCDNにキャッシュされるべきでないページがキャッシュされることにより個人情報の流出が発生してしまうインシデントがありました 自分は動的コンテンツをCDNで配信することにあまり積極的ではない立場だったのですが流出への反応を見るとCDNを利用しているサービスはかなり増えてきているようです 個人情報やユーザーのプライベートデータを決して流出しないようにしつつCDNを利用する方法を考えてみました CDN利用のメリット このふたつ 経路が最適化されレイテンシが小さくなる DDoS対策となる キャッシュされないようにする方法 Twitterで動的コンテンツもCDN通すの当たり前でしょーと言ってる人にリプしてきいてみました CDNとレスポンスヘッダで二重にキャッシュを無効化する キャッシュを細かくコントロールCDNを使う ホワイトリスト方式で特定のパスのみキャッシュを許可 ログインセッションを
概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの２種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の２つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。 しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。 そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。 そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host
Amazon EC2で稼働させているサーバを、Let's Encryptを使ってHTTPS接続に対応させた。高いお金を払わなくても、無料でHTTPS接続が可能になるのだから便利な時代だ。 動作環境 Amazon EC2 Amazon Linux Apache 2.2 導入 下記の手順に従って導入すれば良く、問題は何も発生しなかった。 sudo curl https://dl.eff.org/certbot-auto -o /usr/bin/certbot-auto sudo chmod 700 /usr/bin/certbot-auto certbot-auto certonly --webroot -w /var/www/html -d [server] --email [mail_address] --debug Apacheの設定/etc/httpd/conf.d/ssl.confに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く