XHR2でクロスドメイン通信する際のサーバ側の設定 - Qiita
APIなどを提供しているサーバサイドにいくつかHeaderの設定が必要。 かつ、JSでのリクエストも少しHeaderをいじる必要がある。 サーバサイド Apache Header append Access-Control-Allow-Origin * Header append Access-Control-Allow-Headers Content-Type location / { root /usr/share/nginx/html; index index.html index.htm; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Headers' 'Conte
【何ぞ？】Access-Control-Allow-Origin, クロスドメイン制約, 同一生成元ポリシーって何ぞ【XMLHttpRequest】【JavaScript】【Apache】 - DRYな備忘録
【問題】 anicatch.netというドメインで動いているウェブアプリでHTML+JavaScriptを生成してブラウザに返す。帰って来たJavaScriptの中において、XMLHttpRequestを用い、別ドメイン（今回は api.anicatch.netというドメイン）上で動いているAPIサーバのapiを叩きたい。 で、Access-Control-Allow-Originで許されてないよっ！的なブラウザのエラーを喰らいつづける。 JavaScript文書からapi.anicatch.netを叩いていいのはanicatch.netで生成されたものだけに制限したい。 【調査1】 Ajaxのクロスドメイン問題について HTTP access control (CORS) Access-Control-Allow-Origin試してみた。 jquery - Cross-Domain AJ
[Web全般] HTTPリクエストの全体像：GETとPOST
HTTPのリクエストは、Java, JavaScript, PHP, Objective-Cなど 様々な言語やフレームワークを使って送信するサービス開発を、多々行ってきました。 でも、HTTPリクエストについてちゃんと知ってるかと言うとビミョーな感じで。 今回は、HTTPリクエストについて学んだので、その内容をブログに書きたいと思います。 HTTPリクエストの構成 HTTPリクエストは、大きく3つの部分に分かれるようです。 HTTPリクエスト行 HTTPヘッダー行 HTTPボディ部 GET通信では、上記のうち「HTTPリクエスト行」と「HTTPヘッダー行」を送信して、 POST通信では、「HTTPリクエスト行」と「HTTPヘッダー行」と「HTTPボディ部」を送信するようです。 具体的な構造は以下となっているようです。 HTTPリクエストの中身は、具体的には以下のような内容のようです。 （G
![[Web全般] HTTPリクエストの全体像：GETとPOST](https://cdn-ak-scissors.b.st-hatena.com/image/square/ee271bfadd97facf8dd1934bbb260ceea017f2c5/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2Fs085.png)
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP
Do No Track 実装ガイド
Do Not Track 実装ガイド 第 1 章 : Do Not Track の概要 1 背景 Do Not Track の仕組み トラッキングを巡る議論 プライバシー技術と Do Not Tack » プライバシーポリシー » オプトアウト Cookie と AdChoices » Do Not Trackと法律 第 2 章 : ケーススタディ 11 ケーススタディ 1 : 広告会社 ケーススタディ 2 : テクノロジープロバイダ ケーススタディ 3 : メディア企業 ケーススタディ 4 : ソフトウェア企業 考慮すべきその他の問題 » オプトアウト Cookie » IP アドレス » モバイル端末 » ファーストパーティのホストに設定されるサードパーティ Cookie DNT 対応フローチャート 第 3 章 : チュートリアル 20 チュートリアル 1 : JavaScript
Transfer-Encoding: chunked について - 理系学生日記
Tomcat をコンテナとした Servlet のコード上で Content-Length ヘッダを設定していたのですが、なぜか HTTP レスポンスのヘッダには Content-Length が出力されないという事象が確認されました。 これは一体なぜなのだろうと調べていると、当該レスポンスのヘッダに Transfer-Encoding: Chunked が出力されていることに気付きました。 Chunked は HTTP/1.1 で定義されている方式です。RFC 2068 には以下のような記述があり、Chunked と Content-Length を共存させてはいけない (MUST NOT) ことが分かります。) Messages MUST NOT include both a Content-Length header field and the "chunked" transfer
君は3つのリロードを知っているか？ - os0x.blog
はい、今さら聞けないウェブ開発者の基礎知識のお時間です。 ブラウザには3つの読み込みモードがあることはご存知ですか？ 2つくらいはわかるけど、3つ目が出てこないって方は少なくないかもしれません。 リロード 一番オーソドックスなのがブラウザのリロードボタンを押したときの挙動ですね。普通ですね。 スーパーリロード ブラウザによっては、スーパーリロードという機能を備えています。IEの場合Ctrl+F5(Ctrl+更新ボタン)、Firefoxの場合Ctrl+F5(Shift+更新ボタン)、Chromeの場合Shift+更新ボタン(Ctrl+Shift+R)などでスーパーリロードを呼び出すことができます。スーパーですね。 ページ遷移(リフレッシュ) 3つ目はちょっと良い名前が思いつかないのですが、リロードではなく、通常の画面遷移での読み込みのことです。アドレスバーにフォーカスしてenterするといっ
HttpFox – Get this Extension for 🦊 Firefox (ja)
**DEVELOPMENT STOPPED IN 2014** HttpFox monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers. It aims to bring the functionality known from tools like HttpWatch or IEInspector to the Firefox browser. Information available per request includes: - Request and response headers - Sent and received cookies - Querystring parameters - POST parameters - Resp
Chromeで読み込みに失敗した画像についてリファラを消して再読み込みを試みる方法 - os0x.blog
[追記]実際に使用したい方は @civic さん作のLDR Image Loader extensionをどうぞ。 Chrome Dirty Hacks 01: fc2 image for LDR - 枕を欹てて聴くの別解みたいなのです。要は、livedoor Readerでfc2やアメブロの画像を表示してやろうというネタです。 まず、id:edvakfさんが実験していた edvakf's gist: 48621 — Gist から インラインフレームにdataスキームでhtmlを挿入するとlocationがそのdataスキーム自身になり、そこからのリクエストにはリファラがつかない というテクニックを応用して、さらに errorイベントキャプチャリングフェーズで監視*1して画像のerrorを捕捉 インラインフレームを作ってデータスキームのhtmlを挿入し、そのなかで読み込みに失敗した画像を
Feature matrix of Ruby HTTP clients
I posted Ruby HTTP clients feature matrix which compares various Ruby HTTP client implementations, as a product of Asakusa.rb meetups. I hope Ruby users find it informative. Listed clients: net/http, open-uri, httparty, rest-client, right_http_connection, rufus-verbs, simplehttp, curb, patron, typhoeus, eventmachine, excon, httpclient, faraday, wrest, activeresource and rfuzz. Sample and test scri
[ruby-list:47974] [ANN] Feature matrix of Ruby HTTP clients
Subject: [ruby-list:47974] [ANN] Feature matrix of Ruby HTTP clients From: Hiroshi Nakamura <nahi@ b l g r Date: Fri, 15 Apr 2011 13:56:50 +0900 Ruby用のHTTPクライアントの機能比較表を作りました[1]。（英語の記事） 比較表そのものはこちら[2]。 ご参考までに。 候補としたHTTPクライアント実装は以下: net/http, open-uri, httparty, rest-client, right_http_connection, rufus-verbs, simplehttp, curb, patron, typhoeus, eventmachine, excon, httpclient, faraday, wrest, activ
［無視できない］IEのContent-Type無視
［無視できない］IEのContent-Type無視：教科書に載らないWebアプリケーションセキュリティ（2）（1/2 ページ） XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 無視できないIEの「Content-Type無視」問題 皆さんこんにちは、はせがわようすけです。 第2回では、Internet Explorer（以下、IE）の仕様でも特に悪名高い「Content-Type無視」について説明します。 IEのContent-Type無視問題は非常に複雑で、私自身も完全に説明できる自信はないのですが、それでもセキュアなWebアプリケーションを開発するうえで避けては通れない問題ですので、取り上げることにしました。
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
【レポート】X-Frame-Options、ブラウザ対応完了 | エンタープライズ | マイコミジャーナル
Firefox web browser - Faster, more secure & customizable Firefox 4 Beta 5に導入されたX-Frame-Options機能は、現在のFirefoxリリース版の最新版となるFirefox 3.6.9にも取り込まれている。これですべての主要ブラウザの現行リリース版(IE8、Firefox 3.6.9+、Chrome 4.1.249.1042+、Safari 4+、Opera 10.50+)がX-Frame-Options機能に対応したことになる。 X-Frame-OptionsはHTTPレスポンスヘッダに指定するオプションヘッダのひとつ。レスポンスとして返されるコンテンツをフレームの内部に表示して良いかどうかを指定するといった機能になっている。指定できる値はSAMEORIGINとDENY。SAMEORIGINが指定されている
第２１夜 あなたはJDK6のHTTPサーバを使っているか? - しんさんの出張所 はてなブログ編
JavaでのWebサーバーといえばJavaEEに含まれるServlet APIを利用することが多いと思う。 しかし、そこまで大げさでなくとも･･･という用途は結構あるはずだ。 JDKに簡易Webサーバーが付属しているのを知っているだろうか。 http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/net/enhancements-6.0.html 一番下にある部分がそれだ。 以下サンプル public class App { public static void main(String[] args) throws IOException { HttpServer server = HttpServerProvider.provider().createHttpServer( new InetSocketAddress("local
ブラウザキャッシュとレスポンスヘッダ - murankの日記
ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。 調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論 以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。 キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数 条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻 キャッシュさせたくない場合 Cache-Control: no-cache 調査方法 それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに
DataCache API (Editor's Draft for W3C Working Group Note)
Programmable HTTP Caching and ServingW3C Working Group Note 23 March 2011This version:http://www.w3.org/TR/2011/NOTE-DataCache-20110323/Latest published version:http://www.w3.org/TR/DataCache/Latest editor's draft:http://dev.w3.org/2006/webapi/DataCache/Previous version:http://www.w3.org/TR/2010/WD-DataCache-20100114/Editor:Nikunj Mehta, Invited Expert Copyright © 2011 W3C® (MIT, ERCIM, Keio), All
WordPress.comのHTTPヘッダを見ると
PHPカンファレンスに来ています。 Automattic,Inc.のマクラケン直子さんの発表を聞きつつ、そういえばWordPress.comってnginx使ってたなと思って、Live HTTP headersでレスポンスヘッダを見てみました。 返ってきたのが以下。 HTTP/1.x 200 OK Server: nginx Date: Fri, 04 Sep 2009 04:41:08 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: close Last-Modified: Fri, 04 Sep 2009 04:40:40 +0000 Cache-Control: max-age=2, must-revalidate Vary: Cookie, Accept-Encodin
POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨
あるURLにPOSTでリクエストを発行した結果リダイレクトされたとき，そのリダイレクトのリクエストはGETなのでしょうか?POSTなのでしょうか? なんとなくGETっぽいけど… そこんとこどうなのか気になったので調べてみました．HTTPとかにはあんまりくわしくないので，おかしかったら指摘していただきたいです． 準備 リダイレクトが発生するレスポンスコードは以下の4つです． 301 MOVED PERMANENTLY 302 FOUND 303 SEE OTHER 307 TEMPORARY REDIRECT HTTP1.1のRFCやその解説によると，POSTリクエストした結果，レスポンスコードが302か307だった場合は，POSTでリダイレクトしたほうが良いようです．でも，ほとんどのクライアントはその決まりを守らずGETでリダイレクトしているとも書いてあります． そこで，Firefox/S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apache HttpComponents – Apache HttpComponents