新生鳩丸掲示板♯

>　と言われても、Firefox の問題なのでは。

最近うちのサイトにもFirefoxで頻繁に訪れる方がいて、サーバーは"application/xhtml+xmlをリクエストされた場合だけapplication/xhtml+xmlで返す"設定ですので、私も他人事ではないような気がします。

>　サーバ側で何かできることがありますか?

サーバー側というかHTMLで、onunloadイベントハンドラにCookieを生成する関数を仕込んでおいて、移動したときに値が以前と変わっていれば保存するようにしてみるとか。

JavaScript有効でないと利きませんが、以前からそんな仕組みがほしいと思っていたので、ゴールデンウィーク中にでも実装してみようかと。

>は～い♪

ちょっとくだけすぎました。くだけるのは私の頭だけでよいのです。反省しました。えむけいさん、いろいろありがとうございました。

>なにがどうなのかよくわかりませんが、とりあえずFirefoxの.xpiの場合、Refererが送られなければダウンロードするリソースのURIをもとに情報バーを出すかどうか判定して、Refererが送られればリンク元のページのURIを元に判定します。はっきり言ってホゥルだと思うのですが。

うぅぅうぅ。

>「Webサイトによるソフトウェアのインストールを許可する」の許可リストもhttpsに限定するオプションがありません。

うぅぅうぅ。

>すり替えはできないけどステータスバーやアドレスバーから証明書が確認できない系ですか。そもそも信頼できないサイトのリンクは踏まないことが鉄則ですから前提自体にあまり意味がないと思います。

SSL利用可能なサーバサイド運営側としてはhttpsなページからダウンロードさせるのが真っ当だとあらためて思いました。なので、庶民は信頼できるさきさまのサイトのhttps://なアドレスをもつオブジェクトへのリンクを作るときにはあらかじめよく考えておきましょうということになります。

>もしFirefox以外の話がしたいのであれば新たにスレ立て【謎】を希望します。

は～い♪

>ダウンロードさせる（させたい）オブジェクトそのものにデジタル署名がしていなくて、オブジェクトのURIがhttpsスキームのURL になっていて、それをhttpスキームで開いたページのanchor要素で記述してあったらどうなるのでしょう。なおSSLサーバ証明書はまっとうなものを用意してあるものとし、framesetなど変なのは使っていないサイトであるとします。

なにがどうなのかよくわかりませんが、とりあえずFirefoxの.xpiの場合、Refererが送られなければダウンロードするリソースのURIをもとに情報バーを出すかどうか判定して、Refererが送られればリンク元のページのURIを元に判定します。はっきり言ってホゥルだと思うのですが。

「Webサイトによるソフトウェアのインストールを許可する」の許可リストもhttpsに限定するオプションがありません。

>拡張やプラグインで開く場合、ローカルにあるブラウザとは無関係なアプリケーションで開く場合。OSが開くことになっている場合、など多種ありそうですが、利用者がローカルに保存しにいくケースとナニゲにブラウザの一時ファイルフォルダ（何？）にあるうちに開く場合とがありますし。さて、SSLサーバ証明書には意味が出てきますでしょうか？

すり替えはできないけどステータスバーやアドレスバーから証明書が確認できない系ですか。そもそも信頼できないサイトのリンクは踏まないことが鉄則ですから前提自体にあまり意味がないと思います。

>RFCながめていてもよくわからなかったので何卒ご意見を賜りたく。

>※PDFを自己解答書庫にしてダウンロードさせているサイトがあったこともあり、ちょっと自分の勉強不足を痛感しました。サーバ側で指定するmedia type まで考えると何が一番正しい姿だったのかちょっと不明な気分です。ダウンロードさせるのはなんでもかんでも

>Content-type: application/octet-stream で Content-Disposition: attachment って何か腑に落ちないですし。あうあう。

>ひとつのポストでごった煮に質問を混ぜるのを本当の意味でのマルチポストと言うのではないかとも、たった今思いました。

もしFirefox以外の話がしたいのであれば新たにスレ立て【謎】を希望します。

解凍のtypoです…

話を全然すりかえてしまいますけれどお許し下さい。ぶらさげる場所も意味不明ですけれどお許し下さい。

ダウンロードさせる（させたい）オブジェクトそのものにデジタル署名がしていなくて、オブジェクトのURIがhttpsスキームのURL になっていて、それをhttpスキームで開いたページのanchor要素で記述してあったらどうなるのでしょう。なおSSLサーバ証明書はまっとうなものを用意してあるものとし、framesetなど変なのは使っていないサイトであるとします。

拡張やプラグインで開く場合、ローカルにあるブラウザとは無関係なアプリケーションで開く場合。OSが開くことになっている場合、など多種ありそうですが、利用者がローカルに保存しにいくケースとナニゲにブラウザの一時ファイルフォルダ（何？）にあるうちに開く場合とがありますし。さて、SSLサーバ証明書には意味が出てきますでしょうか？

RFCながめていてもよくわからなかったので何卒ご意見を賜りたく。

※PDFを自己解答書庫にしてダウンロードさせているサイトがあったこともあり、ちょっと自分の勉強不足を痛感しました。サーバ側で指定するmedia type まで考えると何が一番正しい姿だったのかちょっと不明な気分です。ダウンロードさせるのはなんでもかんでも

Content-type: application/octet-stream で Content-Disposition: attachment って何か腑に落ちないですし。あうあう。

ひとつのポストでごった煮に質問を混ぜるのを本当の意味でのマルチポストと言うのではないかとも、たった今思いました。

>　301 はキャッシュしないようにしてみました。

>　たぶんこれで OK だと思います。

>　お手数おかけしました。＞Lucaさん、スターダストさん

よもやま話や用語などをいっぱいリンクさせて頂いていた私の日記をbakera.jpにあわせて全面改訂しました。

…うっかりした操作をしたので「はてなダイアリー」内部に自動的にトラックバックが行ってしまわれたかもしれません。はてなの仕組みって全然学習していないのです。とほほ。

>あの'mixi'がそんな風に見えてしまう，というコミュもあったと思います。

まさしくそのことが日記の本文中に書いてあるように見えますが。

>　誰かが末尾に /index のついた URL にアクセスすると、キャッシュがそれで上書きされて破綻するようですね。むしろ今まで発生していなかったのが謎ですが、何とかします。

　301 はキャッシュしないようにしてみました。

　たぶんこれで OK だと思います。

　お手数おかけしました。＞Lucaさん、スターダストさん

>ひょっとしたら、

>http://bakera.jp/

>から、XHTML鳩丸倶楽部へのリンクを踏んだ後に表示されるページにおいて

>『要求された URL は http://bakera.jp/hatomaru.aspx/index ですが、正しい URL は http://bakera.jp/hatomaru.aspx かもしれません。』と出力されていることに関係があるのでしょうか？

　なんと。ようやく理解しました。

　誰かが末尾に /index のついた URL にアクセスすると、キャッシュがそれで上書きされて破綻するようですね。むしろ今まで発生していなかったのが謎ですが、何とかします。

http://securit.gtrc.aist.go.jp/SecurIT/advisory/referer-2/

> https:// ページから http:// ページへのリンクでReferer:を送出しないことは、 RFCに定められてはおらず、

高木さんともあろうお方【誰】がRFC 2616(しかも「15 Security Considerations」)をご覧になっていないのでしょうか

http://www.ietf.org/rfc/rfc2616.txt

> Clients SHOULD NOT include a Referer header field in a (non-secure)

> HTTP request if the referring page was transferred with a secure

> protocol.

まあMUST NOTでない以上Webアプリケーションがブラウザの挙動をアテにしてはいけないという結論に変わりはないと思いますが。

>>http://bakera.jp/hatomaru.aspxにてリンクされているURIは、http://bakera.jp/ebiで開けませんね。

私もそう思いました。ちょっと書き直すと

http://bakera.jp/hatomaru.aspxにてリンクされているURIは、http://bakera.jp/ebi

になっていまして、期待される

http://bakera.jp/hatomaru.aspx/ebi

ではありません。ひょっとしたら、

http://bakera.jp/

から、XHTML鳩丸倶楽部へのリンクを踏んだ後に表示されるページにおいて

『要求された URL は http://bakera.jp/hatomaru.aspx/index ですが、正しい URL は http://bakera.jp/hatomaru.aspx かもしれません。』と出力されていることに関係があるのでしょうか？

http://bakera.jp/hatomaru.aspx/index

からなら、えび日記は相対リンクで

http://bakera.jp/hatomaru.aspx/ebi

に行きそうです。

あの'mixi'がそんな風に見えてしまう，というコミュもあったと思います。

>http://bakera.jp/hatomaru.aspxにてリンクされているURIは、http://bakera.jp/ebiで開けませんね。http://bakera.jp/hatomaru.aspx/ebiをはてなアンテナに登録して成功しました。

　http://altba.com/bakera/ が http://bakera.jp/ に対応しているので、http://altba.com/bakera/hatomaru.aspx/ebi は http://bakera.jp/hatomaru.aspx/ebi に対応します。

　hatomaru.aspx が無くなったわけではありませんのでご注意ください。

>-version で死ぬ、というよりは、アップデートの過程で何かの整合性が崩れて、 java で何をしても死ぬ状態だろうから、とりあえず -version で試せ、ってことなのでわとおもいました。

　私もそう思いました。

　何をしても死ぬ、という状態になんで気づかないのかと。

-version で死ぬ、というよりは、アップデートの過程で何かの整合性が崩れて、 java で何をしても死ぬ状態だろうから、とりあえず -version で試せ、ってことなのでわとおもいました。

>http://bakera.jp/hatomaru.aspxにてリンクされているURIは、http://bakera.jp/ebiで開けませんね。http://bakera.jp/hatomaru.aspx/ebiをはてなアンテナに登録して成功しました。

ちゃんとhttp://bakera.jp/hatomaru.aspx/ebiへリンクしているように見えますけど? もう修正されたのでしょうか。

http://bakera.jp/hatomaru.aspxにてリンクされているURIは、http://bakera.jp/ebiで開けませんね。http://bakera.jp/hatomaru.aspx/ebiをはてなアンテナに登録して成功しました。

>ていうか多くのアンテナはDateと同じLast-Modified(たとえばwww.geocities.jpがそのような挙動を示す)をspam【謎】として捨てるような実装になってたりして、あまり効果なさげに見えます。

　なんと、そうでしたか。

>やるならDateの5分前とか乱数で決定した別途定める一定秒数前とか【謎】。

　5分前5秒前にしてみました。

ていうか多くのアンテナはDateと同じLast-Modified(たとえばwww.geocities.jpがそのような挙動を示す)をspam【謎】として捨てるような実装になってたりして、あまり効果なさげに見えます。

やるならDateの5分前とか乱数で決定した別途定める一定秒数前とか【謎】。