Amazonの商品ページURLをASINをもとにして作っていたらURLのフォーマットが何パターンかあったのが気になったので調査した。 利用可能なフォーマット 「B00TEY2W72」は商品のASIN番号 https://www.amazon.co.jp/gp/product/B00TEY2W72/ 2016/10時点での正式なURLフォーマット。特に理由がなければこれを使うべきか https://www.amazon.co.jp/exec/obidos/ASIN/B00TEY2W72/ 2007年以前(正式な年月日不明)のフォーマット。一応Amazon側が互換を持たせているので普通に動作するが、あえて使う理由はなさそう https://www.amazon.co.jp/o/ASIN/B00TEY2W72/ 2の短縮版フォーマット https://www.amazon.co.jp/dp/B0
AWS ALB(Application Load Balancer)に長いURLリクエスト投げてみたら、以下のテーブルのように、ある長さのリクエストからエラーが出ることを発見しました。 URLの長さ(Byte) HTTPレスポンスコード 〜16446 200 OK 16447 500 Internal Server Error 16448〜 414 Request-URI Too Large AWSのサポートに聞いたら以下のような制限があることを教えてもらいました。仕様なのでパラメータ等での変更はできないようです。また、旧ELB(Classic Load Balancer)にはこの制限が無いようです。 HTTP headers for Application Load Balancers have the following size limits: Request line: 16K S
It’s 2016. URLs have been used for decades now. You would think they would have consistent behavior. You would be wrong. Conformance A quick visit to the URL constructor conformance test shows that modern specification conformance is poor; no shipping browser passes more than about 2/3 of the tests, and more tests are needed to cover more edge cases. WebKit trunk, which is shipped in Safari Techno
URLのPath部分でURLエンコードした文字列を扱いたい！ Apacheの裏でPassenger動かしている環境において、パス部分にパーセントエンコードされた文字列を含む、たとえば以下のようなURLを扱おうとすると、問題に直面する。 http://example.com/foo/http%3A%2F%2Fexample.org%2Fbar/baz 何がおこるかというと、Railsにわたる前にApacheが勝手にパーセントデコードしてしまうため、 Railsのroutes.rbで受ける段階で、たとえば以下のような記述をしてもちゃんと意図した形でマッチがなされないためだ。 match '/foo/:url/baz' => .. この問題の解決のため（解決にはなっていないのだが）、泣く泣くサービスの外部仕様を捻じ曲げて、扱うURLの中で、以下のようにパーセントエンコードを2重でかけるという手段
galimatias is a URL parsing and normalization library written in Java. Design goals Parse URLs as browsers do, optionally enforcing compliance with old standards (i.e. RFC 3986, RFC 2396). Stay as close as possible to WHATWG's URL Standard. Convenient fluent API with immutable URL objects. Interoperable with java.net.URL and java.net.URI. Minimal dependencies. Gotchas galimatias is not a generic U
URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね？と思っていました。こんな感じに。 これを受け取る側は、JavaScript(node.js)ならdecodeURIComponent()を使っているはずだ。ウェブの世界ではJavaScri
現在は結構な長さが使えるようです。詳細は以下をご覧ください IE : URLに使用可能な文字数 ▼ ( 2013 年当時の実際のお話 ) 必要があって、実際に調べてみました( 仕様では無く GET メソッドでデータが保持された結果の長さをカウントしました ) IE は仕様通りなんですが、融通きかないですね。やっと WebGL 動くようになりましたが、こういうところがおろそかです。
I was able to find several Django-based URL shortening apps, but I didn’t want redirection – I wanted native Base62 URLs. Fortunately, it wasn’t hard to roll up a system from scratch. Started by finding a python function to do the basic encoding – this one did the trick. I saved that in a utils.py in my app’s directory. Of course we need a new field to store the hashed strings in – I created a 5-c
Kalian bisa bernapas dengan lega sekarang, karena telah hadir situs toto terpercaya yang bernama Ojktoto. Koleksi togel online yang ditawarkannya sangatlah beragam dari togel hongkong, toto wuhan, togel sdy, toto macau, togel kamboja, toto sgp dan masih banyak lagi yang bisa dimainkan dengan minimal bet 100 perak. Hadiah toto 4d yang dikasih oleh bandar togel online terbaik ini juga sangatlah besa
To clarify, I’m looking for a decent regular expression to validate URLs that were entered as user input with. I have no interest in parsing a list of URLs from a given string of text (even though some of the regexes on this page are capable of doing that). I also don’t want to allow every possible technically valid URL — quite the opposite. See the URL Standard if you’re looking to parse URLs in
URL normalization (or URL canonicalization) in general is the process by which URLs are modified and standardized in a consistent manner. The goal of the normalization process is to transform a URL into a normalized or canonical URL so it is possible to determine if two syntactically different URLs may be equivalent. For more detail see http://en.wikipedia.org/wiki/URL_normalization Rather than pr
Web ブラウザーは通常 HTTP 要求の Referer: ヘッダーに参照元ページの URL を入れますが (あるいは document.referrer で参照元ページの URL を取得できますが)、 Web サイト側でこれを制御したいことがあります。 例えば、次のような場面が想定されます。 URL にユーザー名や秘密の ID などを含めざるを得ない時は、プライバシーやセキュリティーの観点から、この URL を外部に漏らしたくありません。 社内システムに URL を貼りたいことがありますが、社内システムの URL を外部に漏らしたくありません。 Web アプリケーションの開発用サーバーは、その所在を外部に漏らしたくありません。 投稿者と友達のみに公開される SNS の投稿にリンクが含まれる時、その個別 URL を漏らしたくありません。 (SNS 全体の URL が漏れることは問題ありま
無限スクロールとは、ページの下部までスクロールすると自動的に新しい要素が追加される機能のこと。TwitterなどのSNSのタイムラインを初めとして様々なウェブサイトで使われているが、いくつかの問題点も指摘されている。 無限スクロールのよく知られた問題点と、それに対する解決方法をまとめた。 別のページに移動してから戻ると継ぎ足しがリセットされる リンクがクリックされたときは常に新しいウィンドウを開くようにしたり、 Lightboxのようなモーダルな擬似ウィンドウをページ内に開いたりすることで、ページの遷移そのものを抑制するという方法がある。 また、次の項目で紹介する「History APIでURLを書き換える」という方法を使えば、読み進んだ位置は復元される。 permalinkが取れない 同じページに次々と新しい内容が継ぎ足されていくので、いま自分が見ているページのURLが分からないという問
参照: http://stackoverflow.com/questions/2348399/why-does-java-net-urls-hashcode-resolve-the-host-to-an-ip 公式ドキュメントによると: public boolean equals(Object obj) … 2 つの URL オブジェクトが等しいのは、同じプロトコルを持ち、同じホストを参照し、ホスト上のポート番号が同じで、ファイルとファイルのフラグメントが同じ場合です。 2 つのホストが等価と見なされるのは、両方のホスト名が同じ IP アドレスに解決されるか、どちらかのホスト名を解決できない場合は、大文字小文字に関係なくホスト名が等しいか、両方のホスト名が null に等しい場合です。 ホスト比較には名前解決が必要なので、この操作はブロック操作です。 java.net.URL#equals
CROSS2014の次世代Webセッションを見て来た。 セッションの前半で議論されていたプロトコル編はしっかりとした方向性が示されていたが、後半のアーキテクチャー編は現状の混沌とした話が多くて、方向性というか新しいビジョンを示すまではいけなかった印象だった。 それは、サーバのアーキテクチャーが成熟していることも理由の一つなのかもしれない。 しかし、アーキテクチャーこそ方向性を示すのが重要だろうと思うので、個人的に考えていることをまとめることにした。 Webスケールを実現する技術とリアルタイムWebの方向性 リアルタイムWebというわけではないが、密結合なプロトコルはことごとくインターネットで玉砕されてきた歴史がある。 古くはCORBA IIOP、DCOMの失敗。それからSOAPの失敗。 （ちなみに、IIOPのIはInternetで、当初は大規模なインターネットスケールで分散させようとしたこ
The Public Suffix List is a cross-vendor initiative to provide an accurate list of domain name suffixes, maintained by the hard work of Mozilla volunteers and by submissions from registries, to whom we are very grateful. The usefulness of this can be seen if we take the example of cookies. In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
