Jリーグチケットは正当なメールアドレスを受け付けない - ただのにっき(2019-09-06)
■ Jリーグチケットは正当なメールアドレスを受け付けない (この日記を書いているのはなんと10月1日という……日記ビハインドが一ヶ月近いなんてひさびさだ) わが川崎フロンターレも後期からついにシーズンチケットがデジタル化されて、ICカード1枚が郵送されてくるだけになった。めでたい。いっそアプリ化してくれてもいいんだけど。 で、その余波として行けない試合のチケットを譲渡ないし転売できるようになった。リーグ2連覇していまや毎試合チケット完売しているありさまなので、無駄な空席が出ないのは助かりますな。チケット譲渡・転売の手続きをするにはJリーグチケットのアカウントが必要なので、さっそく登録……しようとしたらエラーになった: おれは訓練されたインターネットユーザなので、この時点でピンときてはいるんだけど、いちおう念の為サポートに連絡してみる。翌日届いた返信がこう: Jリーグチケットでは、@前の1文
RFC8174「RFC 2119のキーワードにおける大文字と小文字の曖昧性」 - ASnoKaze blog
RFCやInternet-Draftを読んだことある人であれば、文中にMUSTやSHOULDといった大文字のキーワードが用いられてるのを見たことあるかと思います。 たとえば、このように An endpoint MUST treat this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR. これらのキーワードはプロトコルの仕様の曖昧性を無くすために 「RFC 2119 Key words for use in RFCs to Indicate Requirement Levels」で定義されています。 しかし、微妙な曖昧性があるためRFC 8174で更新されました。 RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 「MUST」「SHOULD」
HTTP/1.1: They're done. from Mark Nottingham on 2014-06-07 (ietf-http-wg@w3.org from April to June 2014)
From: Mark Nottingham <mnot@mnot.net> Date: Fri, 6 Jun 2014 22:09:10 -0400 To: HTTP Working Group <ietf-http-wg@w3.org> Cc: TAG List <www-tag@w3.org> Message-Id: <21E3BAED-3D08-449A-9F93-B35F3F0DEE3F@mnot.net> Just a quick note - The revision of HTTP/1.1’s specification, obsoleting RFC2616, is complete. See: http://tools.ietf.org/html/rfc7230 - Message Syntax and Routing http://tools.ietf.org/html
テキスト・ファイル向けURIフラグメント識別子
git-release.jsでファイルと行の指定をまとめて設定する良い方法を考えてた。結局はコロンでつなぐという古き良き感じにしたけど、ウェブではこういうのにも使えそうなのをRFC5147 - URI Fragment Identifiers for the text/plain Media Typeで仕様を決めているらしい。何行目かだけじゃなくて何文字目から何文字目までみたいなのが出来るようだ。 以下はExamplesの簡単なメモ。 http://example.com/text.txt#char=100 text.txtの100文字目。 http://example.com/text.txt#line=10,20 text.txtの11から20行目。line=10が10行目と11行目の境界ということ。 https://example.com/text.txt#line=,1 text.
RFC 6694: The "about" URI Scheme
Internet Engineering Task Force (IETF) S. Moonesamy, Ed. Request for Comments: 6694 August 2012 Category: Informational ISSN: 2070-1721 The "about" URI Scheme Abstract This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionali
通信のしくみ（TCP/IP）
通信のしくみ（TCP/IP） [サーバの実験室 基礎] 作成 : 2002/10/12 "サーバの実験室"の検索 TCP/IP インターネットの通信はTCP/IPプロトコル群を用いて行われ、TCP（RFC793）はOSI参照モデルのトランスポート層、IP（RFC791）はネットワーク層にあたる。 ....と書いていくとはまりそうなので、やめる。 RFCはhttp://www.faqs.org/rfcs/あたりを見てね。 ここでは、tcpdumpコマンドを使用して、サーバ・クライアント間でのパケットのやりとりを確認してみる。 tcpdumpコマンド tcpdumpを使用すると、ネットワークに流れるパケットをキャプチャすることができる。 オプションをつけないとデータが膨大になってしまうので、ホストやポートを指定して、対象となるパケットを絞り込む。 ホストAとのパケットを対象とするには、次のよう
HTML5メモ(2) lang属性/日本語に関係する言語タグ の覚え書き - 血統の森+はてな
いつまで続くのかは不明 当然間違いがあるかもしれない。もしあれば遠慮無くつっこんでくれ。 BCP 47というかIANAのレポジトリにあって、HTMLやXMLのlang属性で扱える日本語に関係するであろう言語タグについてまとめてみました。 BCP 47はXML 1.0とHTML5が参照しているRFCです。この文章が書かれた時点での最新のRFCはRFC 5646です。 （RFC 4646を参照しているために少し古いですが）HTMLにおける言語コード/言語タグ メモがたぶん役に立つと思われます。 language（言語）副タグ RFC 5646が見ているのはISO 639-1、639-2、639-3、639-5。日本語に関連すると思われるのは、次の通り。 タグ IANAの説明 ja Japanese ojp Old Japanese jsl Japanese Sign Language jpx
新党のホームページを見てメールアドレスのチェック方法について考えた - ockeghem(徳丸浩)の日記
新政党「たちあがれ日本」のホームページが話題になっていたので私も見てみた。そして、メーリングリストの受付フォーム中に記述されたメールアドレスのチェック用のJavaScriptが気になった。以下に引用する。 if (!node.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){ alert("e-mailアドレスをご確認ください。"); return false; } https://www.tachiagare.jp/mail.php メールアドレスをチェックするための正規表現は、ネット上でたびたび問題視される定番ネタだか、その論点は、RFC(RFC2822やRFC5322)に対して準拠しているかどうかだと思う。例えばこれ(404 Blog Not Found:「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ)。 しかし、現実に
KANZAKI, Masahide on Twitter: "えぇー、「URIというものを細かく分類すると、URLとURNに分けられるのです」なんて書いちゃってるよ。それはRFC 3305でいうところの「古典的見解」で、今の扱いでは、URNはURIスキームの一つというだけの話なんだけど http://bit.ly/aNQKJg"
えぇー、「URIというものを細かく分類すると、URLとURNに分けられるのです」なんて書いちゃってるよ。それはRFC 3305でいうところの「古典的見解」で、今の扱いでは、URNはURIスキームの一つというだけの話なんだけど http://bit.ly/aNQKJg
format=flowed; delsp=yesなメールの処理 - Scrapcode@はてなダイアリー
Apple MailやiPhoneなどからメールを送信すると、受信側のメールソフトによっては、長い行が変なところで改行されて表示されます。 これは、RFC3676の「format=flowed; delsp=yes」というものに従って改行処理がされているためです。 例示のために仮に20バイトで改行されるとして、 あいうえおかきくけこさしすせそ が あいうえおかきくけこ(スペース) さしすせそ のように、改行されたところは「スペース＋改行」になるのです。 そして、メールヘッダのContent-typeが例えば Content-Type: text/plain; charset=ISO-2022-JP; format=flowed; delsp=yes のようになります。 これを「format=flowed; delsp=yes」に対応していないメールソフトで表示すると、行末のスペースの意味を
HTMLに画像も含める、IE8登場後には使うシーンもあるか | エンタープライズ | マイコミジャーナル
SitePoint: New Articles, Fresh Thinking for Web Developers and Designers The "data" URL schemeを使ってWebページやCSSファイルにバイナリデータ、特に画像を含めるというのは、現状においてはバッドノウハウでしかないかもしれない。しかしながらいくつかのレアなケースにおいては有効なテクニックでもある。現状直ぐに採用するといったテクニックではないが、そういった技術があることは知っておいても損はないだろう。 SitePointにおいてMeitar Moscovitz氏がWhy The data: URI Scheme Could Help Save Your Slow SiteのタイトルでThe "data" URL schemeを使う方法を紹介している。The "data" URL schemeはRFC
HTML の id の大文字・小文字の問題 - まじかんと雑記
HTMLに戻したい：メモランダム HTMLで小文字になっているid属性の値が大文字に変換されてしまう問題? そういえばそんな話があったなぁ。 今更だが、俺はこれは大した問題ではないと考えている。というか、これまでの議論では一つ大事な論点が忘れ去られているような気がする。それは、URI の fragment 部分 (# より後の部分) と (case-folding が行われた) id 属性値とを比較する際においても大文字と小文字を区別しなければならないのか、ということだ。 Fragment 部分と id 属性値の比較が大文字小文字の区別無しに行われるならば、何も問題ないではないか。RFC 3986, 3.5 Fragment によれば fragment 部分をどう扱うかはメディアタイプごとに決めてよいことになっている。となると HTML の仕様書に fragment 部分の扱いについてどう
ソフトウェア分野の研究開発 / RFC 5023 Atom Publishing Protocol 日本語訳 | Ricoh Japan
この文書は RFC 5023 The Atom Publishing Protocol を, BCP78によって付託された権利に基づいて日本語に翻訳したものです。 翻訳には誤りがある可能性があります。この翻訳の正確性は保証しません。 翻訳についてのお問合せ先：（SSL対応フォーム） （非SSL対応フォーム） 翻訳者一覧 株式会社リコー 山本陽平 日野原寛 高桑寿一 中川勝樹 沖田邦夫 井上浩一 兵清弘 リコーソフトウエア株式会社 福田朋紀 更新履歴 2008-01-07 日外アソシエーツ株式会社 久我様の指摘を受け 9.7 の訳文をわかりやすく、11.2 の抜けを修正 2007-12-06 9.6、9.7.1、9.7.2、10 の誤記、表記ぶれを修正 2007-11-08 エヌ・ティ・ティ・コミュニケーションズ株式会社 朝倉様の指摘を受け 9.3/9.4 の誤訳を修正 2007-11-0
hxxk.jp - URI 関連の用語の自分用まとめ
記事データ 投稿者 望月真琴 投稿日時 2007-01-05T19:30+09:00 タグ HTML RFC URI まとめ メモ リンク 言葉 概要 RFC3986 をもとに、 URI 関連の用語における自分の曖昧な認識を払拭するためにまとめてみました。いくつか用語が出てきますが、とりあえず URI と relative-ref と path-absolute だけでも理解していれば通常の web 制作では大丈夫ではないでしょうか。それと新年あけましておめでとうございます。 リプライ リプライはまだありません。 パスの話続き <a href="./"> と <a href="/"> はどう違う ? はざっとしたメモ書きだったとはいえ、自分が間違えて覚えていた言葉をそのまま使っていますね。 私はよく仕様や大元の情報をあたるように言っているのに、これではいけません。 ということで、自分の曖昧
hxxk.jp - <a href="./"> と <a href="/"> はどう違う ?
記事データ 投稿者 望月真琴 投稿日時 2006-12-28T02:23+09:00 タグ HTML obsolete URI メモ リンク 概要 この記事は obsolete です。「 URI 関連の用語の自分用まとめ - http://hxxk.jp/2006/12/28/0223 をリライト」 (http://hxxk.jp/2007/01/05/1930#sub-20070105-03) を参照していただくようお願いします。 リプライ 2 件のリプライがあります。 完全パスではない記述のリンク この記事は obsolete です。 URI 関連の用語の自分用まとめ - http://hxxk.jp/2006/12/28/0223 をリライトを参照していただくようお願いします。 同一ドメイン内でのリンクを、完全パス (http:// で始まるリンク ) ではなく相対パスや絶対パスで記
どさにっき - Gmail Mail Fetcher
2006年12月11日(月) ■ Gmail Mail Fetcher _ よそのメールサーバに溜まったメールを Gmail が POP で読み出してくれる機能ができたっていう 記事。 _ が、これができて「完璧になった」だって。これまで実装されてなかったことを批判してきただって。えー。なんで？ _ Gmail がよその POP サーバからメールを拾ってくるには、その POP サーバに自分のアカウントでログインするための情報を google に教える必要がある。Gmail のメールボックスに溜まったメールにアクセスするための情報を google が知ってるというのはおかしなことではない。でも、google とは無関係なサーバに溜まったメールを読み出すための情報を google が知ってるってのは話が違う。google だからどこの馬の骨とも知れない業者ではないだろうけど、それでもれっきとし
studyinghttp.net -
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pecinta Drama
[Studying HTTP] RFC-Translations related HTTP
http://neta.ywcafe.net/000691.html