IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
あるURLにPOSTでリクエストを発行した結果リダイレクトされたとき,そのリダイレクトのリクエストはGETなのでしょうか?POSTなのでしょうか? なんとなくGETっぽいけど… そこんとこどうなのか気になったので調べてみました.HTTPとかにはあんまりくわしくないので,おかしかったら指摘していただきたいです. 準備 リダイレクトが発生するレスポンスコードは以下の4つです. 301 MOVED PERMANENTLY 302 FOUND 303 SEE OTHER 307 TEMPORARY REDIRECT HTTP1.1のRFCやその解説によると,POSTリクエストした結果,レスポンスコードが302か307だった場合は,POSTでリダイレクトしたほうが良いようです.でも,ほとんどのクライアントはその決まりを守らずGETでリダイレクトしているとも書いてあります. そこで,Firefox/S
おお。。。 普通の人なら気にもとめないだろうが、ウェブマスターにとっては嬉しいニュースだ。Google、Yahoo、Microsoftの3社が手を組んで、検索エンジンを正しい方向へ導く非公式の標準規格に対応することになった。 でも、具体的な内容書いてないじゃん。。。>< まあ、英語サイト見たらリンクされてました。各社のアナウンス(?)は以下の通り。 Official Google Webmaster Central Blog: Specify your canonical http://ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ http://blogs.msdn.com/webmaster/archive/2009/02/12/partnering-to-help-s
#!/usr/bin/ruby print "Content-Type:application/xhtml+xml\r\n" print "Content-Type:text/plain\r\n\r\n" print <<EOF Test for How to deal Content-Type EOF たとえば上記のようにわざと Content-Type を二重に出力してしまうと、Apache はバリデートで後者のみがクライアントに返されるが、lighttpd はそのまま二重定義で返してしまう。 これを確認するために、Firefox の Live HTTP headers を使ってレスポンスヘッダを見ても、下記のように Content-Type はどちらも1つしかない。lighttpd の前記の動作を確認することはできない。 Firefox Live HTTP headers Apach
id:HolyGrail (堀愚霊瑠氏) の「はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - id:HolyGrailとid:HoryGrailの区別がつかない日記」とか見てて、色々問題点が指摘されてて、うん、まぁそうだねーとか色々と思いつつ、YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。 で、気になったのは 13. Configure ETags ETagsっていうのはサーバ上のファイルとブラウザのキャッシュが一致しているかどうかを検証するためのものなのですが、正しく利用できていないのであれば、ETagsは無駄なだけなので取り除いてやりましょう、という項目です。 http://s.hat
JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの?ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント(無料)が必要なので、使いたい人は登録しよう! http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い
ウレタン系高反発マットレスでよく言及されるのが密度です。それを頑張って分かりやすく説明してみます。
Expires レスポンスヘッダとか、そのまま使うんじゃなく Date ヘッダの値で減算したデルタ値を使うのが正しい。だってクライアントやサーバの時計があっている保証なんてないから。 #タイムゾーンが狂ってるとかよくあるし freshness_lifetime = expires_value - date_value Hypertext Transfer Protocol -- HTTP/1.1 13.2.4 Expiration Calculations Cookie の expires については定義がないと思うけど、実装としては当然同様にすべき。実際、Firefox のソースコードもそうなってる。 http://lxr.mozilla.org/mozilla1.8/source/netwerk/cookie/src/nsCookieService.cpp#1975
The WinINet functions return error codes where appropriate. The following errors are specific to the WinINet functions. ERROR_FTP_DROPPED 12111 The FTP operation was not completed because the session was aborted. ERROR_FTP_NO_PASSIVE_MODE 12112 Passive mode is not available on the server. ERROR_FTP_TRANSFER_IN_PROGRESS 12110 The requested operation cannot be made on the FTP session handle because
The error values listed below are returned by GetLastError when one of the Microsoft Windows HTTP Services (WinHTTP) functions fails, and are also returned in the lower 16 bits of HRESULT error returns from the WinHttpRequest object. Error values whose names begin with "ERROR_WINHTTP_" are specific to the WinHTTP functions. The WinHTTP functions also return Windows error messages where appropriate
Diagram An activity diagram to describe the resolution of HTTP response status codes, given various headers. The diagram is available in various formats: http-headers-status.gif (205 kb) http-headers-status.jpg (340 kb) http-headers-status.png (447 kb) http-headers-status.svg (315 kb) please see request for assistance below The Visio diagram, published on Google Code Request for assistance
In the beginning the Web had ASCII. And that was good. But then, not really. The Europeans and their strange accents were a bit of a problem. So then the Web had iso-latin1. And HTML could be assumed to be using that, by default (RFC2854, section 4). And that was good. But then, not really. There was a whole world out there, with a lot of writing systems, tons of different characters. Many differe
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
2GBのSDカード買って意気揚々と歓迎会に突撃したらカメラごと持って帰るのを忘れて生きていくのがつらくなったjokagiです. ガジェットには名前と連絡先をお忘れなく. さてウェブアプリケーションの開発をしていると当然ですがブラウザーで画面の確認をしたりしますが,ブラウザーで確認をしているとキャッシュに悩んだり面倒くさいことが少なくありません. 普通そういう時はtelnetなどで直接HTTPプロトコルでウェブサーバーと会話するわけですが面倒くさいですよね. $ telnet www.yahoo.co.jp 80 Trying 203.216.231.160... Connected to www.yahoo.co.jp. Escape character is '^]'. GET / HTTP/1.1 Host: www.yahoo.co.jp HTTP/1.1 200 OK Date:
Movable Type 等で PHP 化や PHP モジュール化によりファイルの拡張子を .php で運用している場合の、サーバ負荷・ネットワークトラフィックを削減する方法をご紹介します。 1.問題点 HTML ファイルの拡張子を .php にしている場合、HTTP/1.1 で規定されている「条件付き GET」が行われません。ブラウザはこのようなサイトに対し無条件に GET を行ってしまうため、サーバ負荷やネットワークトラフィック増加の要因の一つになっています。 2.条件付き GET とは 「条件つき GET」は RFC2616(HTTP/1.1) 9.3 で定義されています。以下和訳を引用します。 RFC2068 9.3 GET(RFC2616は更新版) GET メソッドは Request-URI で識別される (エンティティの形式においての)情報ならなんでも回収する事を意味する。もし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く