Node.jsからほかのサーバーにファイルを送るには、いろいろな方法がある。 ファイルのURLを送り、対向側で別途ダウンロードしてもらう。 ファイルをbase64形式にしてJSONのプロパティで送る multipart/form-data形式で送る JSONを使わない、HTTPリクエストを使わない など？ form-data を使って multipart/form-data で送信する multipart/form-data形式で送る。これは、Webブラウザのformタグが伝統的にやっている方法と同じだ。Node.jsを使うなら、JSONなどを使うほうが楽だが、どうしても multipart/form-data 形式を使いたいケースもある。 ブラウザ側でmultipart/form-dataを使うのは簡単だ。ビルトインクラスのFormDataがある。 async onFileChanged
概要 Visual Studio Code（以下VS Code）の拡張機能であるREST Clientが便利だったのでその紹介です。 使い方を文字とgifで説明していきます。 説明はマーケットプレース以上の情報を足していないので、英語に抵抗がなければ公式ページを照会してください。 REST Clientとは VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できるVS Codeの拡張機能です。 マーケットプレースのREST Clientのページでインストールボタンをクリックするか、VS Codeの拡張機能アイコンをクリックして「REST Client」を検索してインストールボタンをクリックするかで使用できます。 文字だけではイメージし辛いかもしれないので、gifで見てみましょう。 左側のタブがリクエスト、右側のタブがレスポンスです。 ブラウザの拡張機能を使うで
:network_authentication_requiredちなみにこれのRuby元コードはどこにあるかというとrack/rackの/lib/rack/utils.rbにあります。 HTTP_STATUS_CODES = { 100 => 'Continue', 101 => 'Switching Protocols', 102 => 'Processing', 200 => 'OK', 201 => 'Created', 202 => 'Accepted', 203 => 'Non-Authoritative Information', 204 => 'No Content', 205 => 'Reset Content', 206 => 'Partial Content', 207 => 'Multi-Status', 208 => 'Already Reported', 226
Rubyには標準でnet/httpが入っていますが、これはちょっと低レイヤ寄りで使いづらいので、使いやすくしたHTTPクライアントライブラリが多数あります。 ありすぎてどれを選んでいいか調べていたところ、HTTPClientの作者さんによる比較スライドを見つけました： http://www.slideshare.net/HiroshiNakamura/rubyhttp-clients-comparison まとめると httpartyとrest-clientが2大人気（ソースはGemのダウンロード数とgithubのスター数。faradayはラッパーなので別枠） この2つで出来ることはほとんど同じ 違いはDigest認証（httppartyは可）、multipart post（rest-clientは可）くらい どちらもKeep-Aliveに対応していない HTTPClientはDigest
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
[レベル: 初〜中級] HTTPS ではなく HTTP で配信されているすべてのページに対して、通信が安全ではないことを通知するラベルを Chrome ブラウザで常に表示することを Google はアナウンスしました。 2018年7月にリリースされる Chrome 68 から実装する予定です。 全 HTTP ページに「保護されていない通信」ラベルを常時表示 HTTPS で配信していないページ、言い換えれば、HTTP のままで配信しているページには「保護されていない通信」のラベルが URL アドレス欄の先頭に表示されます。 たとえば、今でも HTTP で頑張っている東京都の公式ホームページは、この記事を書いている時点での最新版の Chrome（安定版）のバージョン 64 では、次のように表示されます。 と言っても、気になるところは何もありませんが。 これが、2018年7月にリリースされる C
Webアプリケーションの開発・展開を行っている人々にとって、セキュリティ確保は大きな関心事の1つだといえます。そのためのベストプラクティスやフレームワーク、ガイドラインを提供しているのがOWASP（Open Web Application Security Project）です。OWASPのWikiサイト（OWASP.org）には、Webアプリケーションのセキュリティ確保のための様々な情報がありますが、それらの中でも即効性の高いのが「便利なHTTPヘッダのリスト（List of useful HTTP headers）」だといえるでしょう。 このページには、アプリケーションのHTTPレスポンスに追加することで、事実上無料でセキュリティを強化できるHTTPヘッダが7種類掲載されています。 これらの中でまず活用したいのが、以下の2つのHTTPヘッダです。 X-XSS-Protection 最近
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
旧EMOBILE LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。 スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。 。 契約回線は旧EMOBILE LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。 テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。 この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。 月初めはどのような挙動になるか不明なので来月になったらやってみます。 以下実験結果です。 以下コマンドで1MBのダミーファイルを生成。 % dd if=/dev/zero of=test.zip bs=1M count=1 ファイルの
Hi, I’m Mark Nottingham. I usually write here about the Web, protocol design, HTTP, and Internet governance. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social Saturday, 7 June 2014 HTTP Standards Web Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out. Since 1999, it has served as the definition of
インターネットでしばしば見るエラー番号には、それぞれに意味がある。たとえば、いちばんよく出る「エラー404」は、サーバーの上に指定のページが存在しない、すなわち「見つかりません」という意味だ。 では、「エラー451」の意味はなんだろう？ これはネット検閲を強化しようとする動きを明らかにするために、XML規格の起草者の一人でいまはGoogle社の一員であるティム・ブレイ氏が、2012年5月にウェブの管理機関であるInternet Engineering Task Force（IETF）に提出した、「Unavailable For Legal Reasons（法的な理由でアクセス不可）」を意味する新規のエラー番号だ。 2012年6月、イギリス政府が有名なThe Pirate Bay（TPC）というP2Pダウンロードサイトを封鎖したとき、そのサイトにアクセスしようとした者に対して表示されたエラー
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
「新しいバージョンのHTTPについての作業を開始する機が熟したのではないか」。HTTP 1.1仕様の改版を議論しているIETFのHTTPbisワーキンググループのメーリングリストに1月24日、このようなメッセージが議長のMark Nottingham氏から投稿されました。 現在議論されているのは、RFC2616で規定されたHTTP 1.1仕様のバグや問題の修正などで、基本的にこれまでのHTTPと互換性があることを前提にした仕様です。これが2月にラストコールとなることから、そろそろ次のHTTPについての議論をスタートさせよう、と呼びかけが始まったのです。 HTTP 2.0の議論を含む新しい憲章案も メッセージは、「We're getting close to Working Group Last Call.」（ワーキンググループの作業もラストコールに近づいてきた）と始まります。もうすぐ4年あ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
