PHP の $_SERVER['REQUEST_URI'] と parse_url() の予想外な動作について。 - こせきの技術日記 の続き。 PHPのparse_url()は、 "/abc?a=x&time=09:00&x=y" はパースできるのに、 "/abc?a=x&time=09:00" だと失敗する。 相対URIで「動作しない」仕様だかららしいのだが、それはともかく、コロンのパーセントエンコードが必須なのか気になったので調べた。 URIの仕様 RFC 3986 まず、基礎となる URI の仕様 RFC 3986 がある。 RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax Uniform Resource Identifier (URI): 一般的構文 日本語訳 RFC 1738 - A Gopher URL
URL W3C Working Group Note 06 December 2016 (Link errors corrected 7 Mar 2017) This version: https://www.w3.org/TR/2016/NOTE-url-1-20161206/ Latest published version: https://www.w3.org/TR/url-1/ Previous version: https://www.w3.org/TR/2014/WD-url-1-20141209/ Latest editor's draft: https://url.spec.whatwg.org/ Editors: Anne van Kesteren, Mozilla Sam Ruby, IBM Repository and Participation: Commit h
This document provides guidance on designing RESTful APIs. It recommends using nouns instead of verbs, keeping URLs simple with only two endpoints per resource, and following conventions from leading APIs. Complex variations and optional parameters should be "swept behind the '?'." The document emphasizes designing for application developers by making APIs intuitive, consistent and complete while
URIs, Addressability, and the use of HTTP GET and POST TAG Finding 21 March 2004 This version: http://www.w3.org/2001/tag/doc/whenToUseGet-20040321 Latest version: http://www.w3.org/2001/tag/doc/whenToUseGet (XML) Previous versions: 22 Sep 2003 Draft, 19 Sep 2003 Draft Editor: Ian Jacobs, W3C Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document us
TAG Finding 01 December 2011This version: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111201 Latest version: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState Previous versions: http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111130 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110930 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-2
W3C Recommendation 15 December 2004 This version: http://www.w3.org/TR/2004/REC-webarch-20041215/ Latest version: http://www.w3.org/TR/webarch/ Previous version: http://www.w3.org/TR/2004/PR-webarch-20041105/ Editors: Ian Jacobs, W3C Norman Walsh, Sun Microsystems, Inc. Authors: See acknowledgments (§8). Please refer to the errata for this document, which may include some normative corrections. Se
URI.js is a javascript library for working with URLs. It offers a "jQuery-style" API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority(). URI.js offers simple, yet powerful ways of working with query string, has a number of URI-normalization functions and converts relative/absolute paths. While URI.js p
1. Implementing the Media Fragments URI Specification Raphaël Troncy <rapha[email protected]>, Davy Van Deursen, Erik Mannens Silvia Pfeiffer, Yves Lafon 2. Use Case Aidem received on her Facebook wall a status message containing a Media Fragment URI Use a ‘#’ ! Highlight a video sequence Highlight a region to pay attention to 29/04/2010 - Implementing the Media Fragments URI Specificat
W3C Recommendation 25 September 2012This version: http://www.w3.org/TR/2012/REC-media-frags-20120925/ Latest version:http://www.w3.org/TR/media-frags/Previous version: http://www.w3.org/TR/2012/PR-media-frags-20120315/ Editors: Raphaël Troncy , EURECOM Erik Mannens , IBBT Multimedia Lab, University of Ghent Silvia Pfeiffer , W3C Invited Expert Davy Van Deursen , IBBT Multimedia Lab, University of
探し物をしていて古いリンクをたどったら 総務省｜ご案内ページ －掲載期間が終了しています－ というページにリダイレクトされてしまった。総務省サイトの掲載期間は原則3年で，パンフレットなどは最新版以外は消しているという。国の貴重な資料は永久保存でいいと思うのだが，なぜ消すのだろう？ Webの開祖Tim Berners-Leeは1998年に Cool URIs don't change（神崎さんの訳：クールなURIは変わらない）を書いて，URI（URL）が永続すべきことを説いている。もう10年以上も前のページだが，サイト管理者はぜひ読んでほしい。ここに書いてあるように，何十年も永続させるためにはいろいろな工夫が必要だ。例えば拡張子はその時点での技術を反映する。hoge.html は hoge.cgi や hoge.php や hoge.rb になるかもしれない。そのため，W3Cサイトへの正式な
via reddit 悪用厳禁なハック。Diggなどで新しいニュースを投稿する際に、過去に誰か他の人がまったく同じURLで投稿していると、エラーになってしまうという。 「以前はウケなかったけど自分なら面白い紹介文を書ける」という人は、なんとかしてそのURLをシステムにねじ込みたいかもしれない。そんなときには、サーバやスクリプトエンジンの動きを利用することで、別のURLにして投稿できますよ、というもの。 たとえば、 http://example.com/hoge/ がだめなら、 http://example.com/hoge/./ としてみる。 それから、 http://example.com/hoge/?hoge=hoge などと、無意味なパラメータをつけてみる。パラメータがついても目的のページにアクセスできる場合は、これで重複チェックを飛び越せるというものだ。 メールアドレスもそうだと思
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
クールなURIは変わらないとはよく言われますが、この文章、そしてその題名の意味するところは、最も重要なのは変わらないことであるということだと思うのです。つまり言い換えれば、「変わらないURIこそがクールである」ということであり。 クールなURIは変わらないの後半部分ではURIの設計について述べられていますが、これはあくまで、これから作るウェブページやシステムについて、どんなURIにするかをあらかじめ考えるための指針であり、目的のための手段だと思うのです。目的はやはり「URIを変えないため」であって、これこそがクールであるために欠かせないものです。 クールなURIは変わらないを読んで、「そんなこと言われても、もう".html"とか"/cgi-bin/"が入ったURIでサイトを作ってしまったのにどうしたらいいのか」と嘆く人もいるかもしれません。しかし解決法は簡単で、ただURIを変えなければよい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
