サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
This document discusses the flags which are available to the RewriteRule directive, providing detailed explanations and examples. Introduction A RewriteRule can haveits behavior modified by one or more flags. Flags are included in square brackets at the end of the rule, and multiple flags are separated by commas. RewriteRule pattern target [Flag1,Flag2,Flag3] Each flag (with a few exceptions) has
URL内に「%20（半角スペース）」が含まれていると403エラーが発生します。 １．まずURL内に「%20」があると→403エラー発生。 ２．「whoami20230614 a.php」など半角スペースが含まれた実在ファイルに直アクセス→200OK ３．「?」マーク以降に「%20」があるとき（クエリーパラメーター扱い？）→200OK ４．「/detail_history/?/iuid=314/ab%20cd/?a=12%2134?xyz=1%202」など第一セグメントの後ろに「?/」をつけてアクセス→200OK ５．「%21（!ビックリマーク）」では発生しない。 ４の補足 http://xxx2019.ce99.net/detail_history/iuid=314/ab%20cd/?a=12%2134?xyz=1%202👈403 http://xxx2019.ce99.net/deta
＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
CakePHPをトップディレクトリから利用しています。 http://********/ でアクセスする感じ このとき、 http://********/pc/ へのアクセスは Rewrite させたくないなぁと思い、 htdocs/.htaccess の中に RewriteCond を指定したのですがどうにこうにも上手くいきませんでした。 なんでじゃぁぁぁ とクタクタになりかけたその時、こちらのサイトの一文がすごく参考に‥。 .htaccessの書き方 （murashun.jp） RewriteCondの処理順は、どうやら先に RewriteRule をマッチングで確認し、その後にその上に書かれている条件 RewriteCond のマッチングをして処理にすすむ仕様のようです。 つまり、 とかかれている場合は、まず条件 C にマッチして、かつ A が B にマッチする場合は HOGEEEE
環境AWS EC2WordPress Certified by Bitnami 実装 $ cd /opt/bitnami $sudo apache2/bin/htpasswd -cb apache2/wordpress_users USERNAME PASSWORD $sudo vi /opt/bitnami/apps/wordpress/conf/httpd-app.conf 以下に書き換える。 4行追加 & Require all grantedをコメントアウト <Directory "/opt/bitnami/apps/wordpress/htdocs"> ... AuthType Basic AuthName MyAuthName AuthUserFile "/opt/bitnami/apache2/wordpress_users" Require valid-user .
一杯書いてるけど、シンプルにいえば、 Authと転送は両立できない。転送を諦めて、SSLRequireSSLを.htacessに書くだけ。 Basic認証を見直してみる Basic認証は手軽で便利です。Rediscover Basic認証。Basic認証を使うことで、LDAP連携が出来るしDBMや、MySQLをバックエンドに使えたり。ノウハウを確立しておくと意外と重宝する。 簡単に言えば Apacheの認証＝ require valide-user を使う。 パスワードが経路で丸見えになるのであまり使われない。でも便利。 そこでHTTPSで使うことになる。Basic認証とHTTPSで、一応は安心で簡単な認証とアクセス制限を実現出来る。 Basci認証はHTTPの正式な認証手段 HTTPのヘッダにちゃんと定義されている WWW-Autenticate ヘッダがあるのでブラウザは必ず実装するの
mod_rewriteを使ってURLを書き換えている時に、URL中の & （アンパサンド）がURLエンコードされなかったので、その対策を考えてみた。 具体的にどういうことかというと、、、 例えば、何かの検索システムで Love&Peace という単語で検索したいとする。書き換えルールは次のような感じで mod_rewrite を使う。（なお、 & マークはURLエンコードされ %26 で表されている。） http://example.com/search/Love%26Peace みたいなURLをmod_rewriteを使って http://example.com/search/search.php?q=Love%26Peace にしたいとする。 この場合、通常であれば、 RewriteRule ^search/(.*)$ /search/search.php?q=$1 みたいな感じでい
動的なプログラムでコンテンツを管理している場合、HTTPヘッダを制御できるのでキャッシュコントロールがしやすいですが、静的なHTMLだけの場合はキャッシュの制御がかなり難しい状況になります。HTMLの場合、METAタグにcache-controlやExpiresを入れるやり方が一般的ですが、この方法はブラウザによって動作にばらつきが出たりそもそも動作が安定しなかったり、プロキシなどを介するN/W上ではMETAタグは無視されるのでうまくキャッシュを制御することができません。 今回の内容は、コンテンツをキャッシュさせるというやり方ではなく、静的なコンテンツしか動いていないWebサーバーという状況下で、コンテンツをキャッシュさせたくない場合の対応方法を書いていきます。 先ほども書いたように動的なプログラムを扱っている場合はHTTPヘッダを制御できますが、静的なHTMLだけではHTTPヘッダを制
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
