Big Sky :: Re: Go言語で画像ファイルか確認してみる
Go言語で画像ファイルか確認してみる - Qiita Go言語で書かれたサーバーサイドでアップロードされたファイルが画像ファイルか確認する必要があったため今後の備忘録として記載します。 https://qiita.com/tebakane/items/b7a47379659d42364c8d 実は Go にはそれ専用の関数が用意されています。 http package - net/http - Go Packages Package http provides HTTP client and server implementations. Get, Head, Post, and PostFo... https://pkg.go.dev/net/http#DetectContentType バイト列を指定して以下の様に呼び出すだけです。 ct := http.DetectContentTy
WebTransportでもプロトコル理解がしたい! - Qiita
2023/12 この記事はだいぶ古く、理解が足りていないところが多々あります。 最近のWebTransportについては下記の記事にまとめてあります。 前回のechoサンプルを少し改良しました。 前回はechoサンプルを動くようにしましたが、 今回はHTML側に切断処理を入れ、WebTransportのセッションが閉じられた時にQUICのイベントログを出力するようにしました。 今回はそのログも合わせてプロトコルを理解していきます。 ソースコードはこちら WebTransport? HTTP/3?? QUIC??? 何それおいしいの? WebTransportに何となくワクワクと闇の気配を感じている皆様こんにちは。 今回は前回のechoサンプルとドラフトを睨めっこしながらプロトコルについて理解していきたいと思います。 ここではChrome M97に実装されている WebTransport o
セキュリティエンジニア向けマテリアル - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 脆弱性・脅威情報収集用の巡回サイト一覧やユーザ・偉い人向けの説明資料，また，手帳に挿んでいると便利なドキュメント類をご紹介します． 実際の調査対応に使うツールについては，こちら（Windows編）とこちら（Linux編）をご参照ください． 渦中のサイトや怪しい情報源に訪問するときは，TORブラウザなどを使うことをお勧めします． （適宜更新中） 脆弱性・脅威情報収集 piyolog http://d.hatena.ne.jp/Kango/ ホットなセキュリティインシデントのまとめサイト．タイムリー． 運営しているPiyokango氏のTw
Cookieを永続化して、どこまでも個人を追跡するEvercookie - Qiita
Evercookieは、ブラウザに究極的に永続的なCookieを生成するJavaScript APIです。 その目的は、標準的なCookie、Flash Cookieなどを削除した後でもクライアントを識別し続けることです。 これは、可能なかぎり多くのストレージにCookieデータを保存することで達成します。 いずれかのストレージからCookieが削除されたとしても、ひとつでも残っている限り、Evercookieは残ったデータからCookieデータを復旧します。 Flash LSO、SilverlightもしくはJavaが有効な場合、Evercookieはブラウザを超えて同じクライアント上の別のブラウザにCookieを伝播することすら可能です。 本リポジトリは、Samy Kamkarおよび多くのコントリビュータによって作られています。 Browser Storage Mechanisms E
何もしなくても運が悪いとApacheは落ちる - Qiita
TL;DR Apache2.4.26より前のauth_digest_moduleにはバグがあり、低確率でApacheが死ぬことがある。 経緯 ほぼ自分専用で他所からは誰も来ないWebサーバを数年運用しています。 運用というか放置ですが。 開設当初にある程度の設定を行いましたが、その後は何年も更新せずに、それどころかSSH接続することすらほとんどなくほったらかしでした。 私は環境構築マニアではないので、現在動いているサーバには何もしたくないのです。 セキュリティ？知らんな。 そんなでもこれまで数年間何の問題もなく動いていたのですが、なにやら先日突然Apacheが止まりました。 調査 とりあえずApacheのステータスを確認。 ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/htt
HTTPのバージョンについて、現在のまとめ - Qiita
はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H
Rustで高速に大量のHTTPリクエストを投げる - Qiita
自己紹介 趣味でRustをやっている Twitter https://twitter.com/hatookov Github https://github.com/hatoo SoundCloud https://soundcloud.com/gfyxxqjngkze ネットワーク初心者なので誤りがあるかも知れません Rustで高速に大量のHTTPリクエストを投げる モチベーション oha HTTPロードジェネレータ Apache Bench(ab)みたいな tui-rsでリアルタイム表示 とにかくいっぱいリクエストを投げたい！ ベンチマーク環境 WSL 2 Ryzen 3950x 今回はtokio https://github.com/hatoo/rust_http_benchmarks ベンチマーク雛形 ベンチマーク系のライブラリは複数回実行してしまい、時間がかかるのでやめた ざっくり
QUIC, HTTP/3, Web関連の標準化トピック (IETF 107) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? IETFで議論されている、HTTP/3やWeb関連の応用トピックについて、次回ミーティングセッションに合わせ紹介していく。 IETF 107について QUICやHTTP/3は現在IETFで標準化が進められています。 そんなIETFの107回目のミーティングが今週(3/23~27)から開催されます。元々はバンクーバーで開催予定でしたが、急遽リモートでの開催となりました。 それに合わせ、開催セッションも少なくなっています(Agenda参照)。開催されるセッションは、今後の作業の進め方を決める必要がある初開催のWGや、BoF（同じ課題に興味を
QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog
2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com 目次 Status The Plan Versions Extensions Applications Other Things More Information 関連記事 QUICは現在IETFで標準化が進められているトランスポートプロトコルであり、HTTP/3はそのQUICの上で効率よくHTTPのメッセージをやりとりするプロトコルです。 ChromeやFirefox, Nginxなどがすでに実装を行っており、「相互接続テスト」を定期的に実施している。その他多くの実装があり、「Implementations」から確認ができる。 その標準化状況について、QUIC WGとHTTP WG両方のチェアを務めるMark Nottinghamが先週行われたIETFで発表した「Quick QUI
nghttp3を使ってcurlでHTTP/3通信する - Qiita
Cloudflareが作成したrust製のQUICライブラリ、quicheを使ったcurlでのHTTP/3通信は以前の記事を使って実現できましたが、ngtcp2とnghttp3を使ったcurlのビルドが上手くいかず、放置してました。 今日やってみたら動くようになってたのでうれぴーって感じです。 こんなかんじ。 $ docker run --rm -it inductor/curl-quic-ngtcp2 # curl --http3 https://facebook.com/ curl --http3 https://www.facebook.com/ -v -s -o /dev/null * Trying 31.13.82.36:443... * Connect socket 3 over QUIC to 31.13.82.36:443 * QUIC handshake is compl
http.ListenAndServe() をインターネットに公開してはいけない - Qiita
http.ListenAndServe() を使ったサーバーをプロダクションに投入していたのですが、海外からのアクセスが多くなったころにリソースリークが発覚しました。 ListenAndServeのドキュメント ListenAndServeのソースを見るとこうなっています。 func ListenAndServe(addr string, handler Handler) error { server := &Server{Addr: addr, Handler: handler} return server.ListenAndServe() } addr, handler 以外は http.Server のnil値がそのまま使われている事がわかります。この構造体にはいくつかのタイムアウト値がありまが、nil値で初期化されるとタイムアウトなしの状態になってしまいます。 Server型のドキ
HTTPサイトのドメインを奪われてHSTSを有効化されたら - Qiita
はじめに 最近lovelive-anime.jpドメインが何者かによって移管され一時的にその者の手に渡った。もともとの管理者によってすでに取り戻されたが、攻撃者は一時的にこのドメインに対する全権を握った。この記事では、あくまでも思考実験として攻撃者が他人のHTTPサイトを運用しているドメインの全権を握ったときに、攻撃者が**HSTS(HTTP Strict Transport Security)**を有効にしてしまった場合どうなるかについて考える。まずはHSTSについて簡単に説明し、そしてその後で今回筆者が考えた攻撃について議論し、最後にまとめを述べる。 この記事を読んでわからないことや改善するべき点を見つけた場合は、気軽にコメントなどで指摘してほしい。 攻撃者によるHSTSの有効化 ここではHSTSに関する説明と、筆者が考える攻撃（？）について説明する。 HSTSとは HSTSとは、HT
Kotlin コルーチンでネットワーク I/O 処理実験 - Qiita
Kotlin のコルーチンを勉強中。 Kotlin のコルーチンは、Python のコルーチンのようにシングルスレッドで実行されるわけではなく、スレッドプールを用いた M:N スレッドモデルが採用されている。 Java を使うことは近年ほとんどなかったので余り知識がないところではあるが、Java のネットワーク I/O 周りの処理は基本的にブロッキングするものだと捉えている。著名な HTTP ライブラリもそのはず。 そのようなブロックするネットワーク処理を同時に多数実行しようとした場合、コルーチンを使って非同期に扱ったとしても、バックグラウンドのスレッドがブロックしてしまうので、結局は多くのスレッドを生成しなくてはいけないのではないか？ スレッドは高価なのでリソースが枯渇してしまうのではないか？ そのような疑問が生じてきた。 Go の Goroutine も M:N スレッドモデルだが、ブ
HTTP/3が出るらしいという話を雑に書く - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 インターネットに関する技術の標準化を司る、IETF(Internet Engineering Task Force)のWG(Working Group)において、HTTP-over-QUICが正式にHTTP/3という名前になることで合意が取れました。(ゆきさんからのご指摘内容を修正しました) しかし、そもそもこのQUICやHTTP/3って何なんでしょうか？ Webに関わる僕たちエンジニアにとってどういう関わり方をするのか、考えてみました。 この記事は怪文書ですので、雑と書いてあるところは私見として軽く流してください。 追記 詳解H
HTTP 418ステータスコードが予約される - ASnoKaze blog
「418 I’m a tea pot」としてよく知られる 418 ステータスコードについて、IETF HTTPbis WGで議論になっていました。 「418 I’m a tea pot」はジョークRFCである「RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)」で定義されているステータスコードです。 ここで注意するのは、418はHTCPCPで定義されているステータスコードであり、HTTPで定義されているステータスコードではないという点です。 この議論については以前 Qiita で書いたとおりです。 qiita.com HTTPで418ステータスコードを予約 以前このブログで書いたとおり、HTTPセマンティクスに関して仕様の再改定が行われております asnokaze.hatenablog.com その後、3つの仕様に分割され
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NFL/STREAM]] Pro Bowl AFC vs NFC Live/Stream - Qiita![NFL/STREAM]] Pro Bowl AFC vs NFC Live/Stream - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/cbc1f0f7d57c0fbd7dc87d81bc07542c36a83eff/height=288;version=1;width=512/https%3A%2F%2Fcdn.qiita.com%2Fassets%2Fqiita-fb-2887e7b4aad86fd8c25cea84846f2236.png)