JavaScriptが解釈できないクローラーが正しくogpタグを読めるようにするために、どのようなアーキテクチャでSPAのサイトを構築すればいいかというお話Read less
![SPA時代のOGPとの戦い方](https://cdn-ak-scissors.b.st-hatena.com/image/square/3d70e6e433fb285c8d5be7b736e8eb1b4c1ea0ea/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Ffightagainstogpinspaera-181117081234-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
JavaScriptが解釈できないクローラーが正しくogpタグを読めるようにするために、どのようなアーキテクチャでSPAのサイトを構築すればいいかというお話Read less
[小ネタ] CloudFrontでクエリ文字列を転送しているときのInvalidationにはクエリ文字列を忘れないように注意しよう Amazon CloudFrontでクエリ文字列をオリジンに転送するよう設定していてキャッシュクリアを行う場合には、Invalidationのパス指定の際にクエリ文字列部分も考慮しないと、クエリ文字列を含んだリクエストについてはキャッシュが無効化されません。 はじめに 清水です。タイトルのとおりなのですが、Amazon CloudFrontでクエリ文字列をオリジンに転送するよう設定している場合でInvalidation(ファイルの無効化)を行う際には、Invalidation対象のパスにクエリ文字列を含める必要があります。(クエリ文字列部分のワイルドカードの利用も可です。)Cookieやヘッダーをオリジンに転送している場合は対象となるパスのみを指定すれば良い
こんにちは、せーのです。今日はCloudFrontを使っている方にちょっと便利になったアップデートをご紹介します。 invalidationがちょっと楽になった CloudFrontで配信を行う場合、当然ながらキャッシュコントロールが重要なポイントとなります。スタイルシートやロゴ画像等、ほとんど触ることのないようなファイルはTTLを数ヶ月、1年と長めにとって置くことでCloudFront内に保管され、コストの節約になりますが、Webシステムなどでは定期的に変更するヘッダ画像等こまめにキャッシュを消さなくてはいけない運用も存在します。またポータルサイトを運営している方はユーザーの退会処理に伴いそのユーザに関わる全ての画像を消す必要が出てきます。アイコンはもちろん、SNSのようなサイトであればプライベートな画像も多いですから、きちんとポリシーを設けて確実にキャッシュを消していかないと権利的にも
特に問題となるのがS3の場合でした。EC2インスタンス上のWebアプリケーションであればOriginヘッダの有無に関係なくAccess-Control-Allow-Originヘッダを返すこともできますが、S3のCORS機能は仕様通りの実装であるためOriginヘッダが存在しない場合はAccess-Control-Allow-Originヘッダを返しません。具体的には、以下の様な挙動になります。まずはOriginヘッダをつけない(同一ドメイン)の場合です。curlコマンドでStatic Website Hostingを有効にしたS3バケットhoge.example.com.s3-website-ap-1.amazonaws.comに対してアクセスします。 $ curl -I hoge.example.com.s3-website-ap-1.amazonaws.com/hoge HTTP/1
ども、大瀧です。 本日、AWSのCDNサービスCloudFrontのキャッシュ無効化(Invalidation)高速化のアナウンスがありました。 AWS Developer Forums: Announcing Fast Invalidations 試してみた様子をレポートします。 CloudFrontのキャッシュ削除にかかる時間 CloudFrontのキャッシュ削除は、コンテンツのパス単位(ワイルドカード指定も可)で従来10〜15分程度かかっていたものです。今回のアップデートで、CloudFrontエッジロケーション(キャッシュサーバー)の90%には5秒で、全体には1分で削除が行われるようになりました。同時リクエスト数や料金などのルールは従来通りです。 では、手元のCloudFront Distributionで試してみます。キャッシュ設定は以下の通り、60秒キャッシュする状態(Defa
はじめに S3をWebコンテンツの置き場所として使う場合、Webアプリケーション側でそのS3上のコンテンツに対するPre-signed URLを生成することで、Webアプリケーションで認証されたユーザに限りコンテンツにアクセス可能とするような仕組みを作ることは良くあります。 ただしこのS3アクセス用として生成したPre-signed URLは、CloudFrontを経由した形では使えません。 CloudFront経由で、限られたユーザのみS3からコンテンツを取得出来るようにするためには、CloudFront用の署名付きURLを発行する必要があります。 そこで今回は、CloudFront+Amazon S3を組み合わせて、署名付きURLを使った制限されたコンテンツ(プライベートコンテンツ)の配信を試してみました。 やってみる 今回試したことは、以下のAWSのドキュメントを参照しながら行ってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く