並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 754件

新着順 人気順

HTTPの検索結果121 - 160 件 / 754件

  • Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる

    const url = "https://fetch-api-normalization.deno.dev"; await fetch(url, { method: "PATCH" }); await fetch(url, { method: "patch" }); 実行すると、次のようなエラーを得るはずです。 PATCH を小文字で書いた際のエラーの一例 さて、どのような条件でこのエラーが発生するのでしょうか?これが意図されたものなのだとしたら、 GET や POST は大文字・小文字を無視してよくて PATCH は無視できない理由がなにかあるのでしょうか?以下でその理由を探ってみましょう。 いつエラーが発生するか このエラーは、 Fetch API を利用して外部の HTTP サーバーに対してリクエストを行う時に、 PATCH と書くべきところを patch と書いていると発生します。

      Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる
    • 死ぬまでhttp://って無くならないのかな

      家を整理してたら大昔の雑誌が出てきたんだけど、インターネットが流行り始めてた時期のものだったみたいでいろんな広告にデカデカと「http://www.なんたらかんたら.net」 みたいなURLが記載されてて、わー懐かしいと思ってたのね。 けどよくよく考えたら令和になった今の広告やら名刺やらにもhttps://って載ってたりするな、ということに気が付いて、なんだかちょっと不思議な気持ちになった。この表記思いの外長寿じゃない? インターネット出始めの頃ってhttp://www.っていう部分がいかにも一般向けのことは考えずに作った仕組みです感があって、仮っぽいというか生っぽいというか、良くも悪くもちょっと怪しい感覚があって、まあそのうち仕組みも整えられるだろう位に思ってたんだけど、検索エンジンが出てきてもなおhttp://は生き残り続けてるわけだ。 インターネットを作った人は全世界の人が使うように

        死ぬまでhttp://って無くならないのかな
      • 「ピアリング戦記 - 日本のインターネットを繋ぐ技術者たち」を書きました!:Geekなぺーじ

        書名:ピアリング戦記 日本のインターネットを繋ぐ技術者たち 著者:小川晃通 著 発行:2022年7月13日 ISBN:978-4-908686-14-6 A5判、152ページ 紙本体2000円 電子本体1800円 インターネットを構成する「技術」は世界共通です。 その仕様であるTCP/IPは万人に対して公開されており、解説書も数多くあります。 仕様や解説書は体系的に記述されているので、一見するとインターネットは実に合理的に技術的な要請に基づいて構成された形をしているように思えるかもしれません。 しかし、インターネットは人間が作り運営しているものです。 そのため、インターネットの形には「人間の営み」が少なからず影響しています。 そもそもインターネットを物理的に構築するためにはどうしても各所でお金が必要です。 回線代、場所代、電気代、運用者の人件費など、維持にはさらにお金がかかります。 お金が

        • 逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

          『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse

            逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
          • はてなスターのひみつ - Hatena Developer Blog

            ハッピーホリデー!id:cockscombです。この記事ははてなエンジニアAdvent Calendarの8日目のエントリです。 今年1月、はてなスターのリニューアルを行いました。リニューアルの内容は告知をご参照ください。 はてなスターのリニューアルでは、クロスオリジンの問題を解決するために特別な実装をしています。今回は、ホリデーシーズンをお祝いして、そのひみつを詳 (つまび)らかにします。 はてなスターとクロスオリジン はてなスターは、はてなブログなどに埋め込んで利用されます。はてなブログは hatenablog.com や hatenadiary.jp などのサブドメインを利用しており、さらにはてなブログProでは独自のドメインを設定できます。 はてなスターは複数の異なるドメイン名のサイトから利用される、ということです。 要するにはてなスターはクロスオリジンで利用されます。一方ではてな

              はてなスターのひみつ - Hatena Developer Blog
            • HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として

              HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として 現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF(Internete Engineering Task Force)により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。 QUIC is now RFC 9000 | Fastly QUIC is RFC 9000 | daniel.haxx.se QUICはもともとHTTPをより高速化するためにGoogleが開発し、その後IETFで標準化が進められてきました。 QUICはまずは次世代のHTTPであるHTTP/3のトランスポート

                HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として
              • Webサーバの仕組みについて入門してみた(Python実装) - iimon TECH BLOG

                はじめに 株式会社iimonでSREエンジニアをしているhogeです。 本記事はiimonアドベントカレンダー9日目の記事となります。 今回の記事は技術的な棚卸しとして、普段大変お世話になっているWebサーバがどういった仕組みで動いているのかを実装しながら深堀りしていこうと思います。 弊社のバックエンドはDjango/FastAPI + Gunicornの構成で動作しているため、Pythonを絡めた説明が多くなるかと思います。サンプルコードもPythonで実装をしています。 途中、システムコールやファイルディスクリプタなどにも踏み込んだ話をするのですが、低レベルなプログラミングをちゃんとやったことがないため、間違えている部分があるかもしれません。今後学習して行く中で気づいたら都度修正していきたいと思います。 環境・使用ツール 言語 Python OS Ubuntu(Linuxのシステムコー

                  Webサーバの仕組みについて入門してみた(Python実装) - iimon TECH BLOG
                • Hurl - Run and Test HTTP Requests

                  What’s Hurl? Hurl is a command line tool that runs HTTP requests defined in a simple plain text format. It can chain requests, capture values and evaluate queries on headers and body response. Hurl is very versatile: it can be used for both fetching data and testing HTTP sessions. Hurl makes it easy to work with HTML content, REST / SOAP / GraphQL APIs, or any other XML / JSON based APIs. # Get ho

                  • 【徹底解説】REST VS GraphQL

                    注意:今回の記事で載せているコードは読者に具体的なコードのイメージを持たせる目的で書いている。それ故に、実際にブラウザ上で実行しても動作しない点には注意してほしい。より専門的ににGraphQLとRESTの違いを学びたいならLogRocketの記事とApolloの記事を参考に。 はじめに 今回の記事では、Web APIの開発に重宝されるRESTとGraphQLの違いを解説する。 対象とする読者 これからREST、またはGraphQLを実務で積極的に活用したいひと 両者の違いがわからないひと 個人開発等でWeb APIをつくるひと タイトルを見てなんとなく気になったひと APIとは RESTとGraphQLの議論に入る前に、まずはAPIについて説明する必要がある。 Wikipediaによると、API(Application Programming Interface)は以下のように定義されてい

                      【徹底解説】REST VS GraphQL
                    • RESTful APIのURI設計(エンドポイント設計) - Qiita

                      HTTPメソッドとURI HTTPメソッドとエンドポイントは切っても切れない関係にある。URIがリソースを表すものだとすると、HTTPメソッドは操作(何をするか)を表すものである。1つのURIのエンドポイントに異なるメソッドでアクセスすることで、情報を取得するだけでなく情報を変更したり、削除したり等のさまざまな操作を行うようにすることで、リソースとそれをどう扱うかをきちんと分離して扱うことができる。これはHTTPメソッドの本来の考え方に合致しており、Web APIではこの考え方に沿って設計を行うことが主流となっている。各HTTPメソッドについては以下を参照。 リソース指向アーキテクチャの統一インターフェース URI設計 リソースにアクセスするためのURI設計の注意点 1.複数形の名詞を利用する 基本的にリソースは「集合」を表すものであるため、複数形の方が適切である。また、HTTPのURIは

                        RESTful APIのURI設計(エンドポイント設計) - Qiita
                      • フロントエンドエンジニアも知っておきたい HTTP/3 で変わること

                        フロントエンドカンファレンス沖縄 2023 の登壇資料です

                          フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
                        • Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に

                          Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。 Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しつつ、従来と比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。 Pingoraは現時点でコードなどは公開されていませんが、いずれオープンソース化の計画についても明らかにするとCloudflareは説明しています。 Today we are excited t

                            Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に
                          • ChatGPTをぬるぬるにする🐌Server-Sent Eventsの基礎知識

                            単方向通信であるということと、HTTP/1.1上で動作しているのが大きな特徴です。 また、HTTP上で動作することから、通信の互換性が高く、セキュリティモデルも使いまわせるので安心です。 どんな用途と相性がいいの? 双方向通信がしたいわけでなければ、相性の幅がとても広いです。 今回の ChatGPT のような、GPT がトークンを生成するごとに送るケースはもちろん、通知の未読件数バッジの更新、ニュース速報の表示など、サーバからイベントを送りたい時ならなんでも使えます。 HTTP/1.1で動くカラクリ SSEはHTTPのレスポンスヘッダにContent-Type: text/event-streamを指定した上で動作します。 SSEが動く流れ クライアントがサーバーに HTTP/1.1 リクエストを送信し、イベントストリームに接続します。 サーバーは、Keep-Alive 接続を使用して、T

                              ChatGPTをぬるぬるにする🐌Server-Sent Eventsの基礎知識
                            • 【海外記事紹介】「モダンCSSがあればSPAは不要」と主張するブログが話題に

                              7月25日、Jono Alderson氏が「It’s time for modern CSS to kill the SPA」と題したブログ記事を公開し、海外で話題を呼んでいる。 7月25日、Jono Alderson氏が「It’s time for modern CSS to kill the SPA」と題したブログ記事を公開し、海外で話題を呼んでいる。 この記事では、モダンCSSとブラウザ標準機能がシングルページアプリケーション(SPA)の利点を置き換え、マルチページアプリケーション(MPA)への回帰を促す潮流について詳しく紹介されている。以下に、その内容を紹介する。 「アプリのように見せたい」思考の罠 従来、サイトを“アプリらしく”見せる最も手軽な手段はSPA (Single Page Applications)だった。ReactやVueを使い、クライアント側でルーティングと描画を担

                                【海外記事紹介】「モダンCSSがあればSPAは不要」と主張するブログが話題に
                              • WebSocket 入門

                                注意:今回の記事はあくまで初心者向けにWebSocketの概要を理解してもらうために執筆されている。そのため、一部正確性を欠く可能性がある。詳細にWebSocketについて学びたいならMicrosoftの解説記事やWebSocket Protocolを確認してほしい。 はじめに 今回の記事ではWebSocketを解説する。 対象とする読者 WebSocketについてわからないひと WebSocketとは? WebSocketは双方向のHTTPプロトコルで、クライアントとサーバの通信で成立する。HTTPとは異なり、ws://あるいはwss://から始まる。WebSocketはHTTPとは違って、クライアントとサーバ間の接続はどちらか一方が切断されると終了する。WebSocketが動く仕組みはHTTPのそれとは異なり、ステータスコード101がプロトコルの切り替えを示す。 WebSocketが動

                                  WebSocket 入門
                                • Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ

                                  僕としてはGoのおすすめのフレームワークを聞かれたら、標準ライブラリのnet/httpと答えるようにしています。というよりも、Goの他のフレームワークと呼ばれているものは、このnet/httpのラッパーでしかないからです。 Goでアプリケーションを作成する場合のイメージは次の通り。battery includedなアプローチは他の言語でもたまにありますが、ついてくる機能が今時のものが多くて、標準ライブラリで済むことが多いです。ウェブ開発についてもそんな感じです。 PythonとかRubyとかもそうですが、言語組み込みのウェブサーバー機能はテスト用で本番運用には機能が足りない、性能が足りない、ということから「プロダクションに耐えうるフレームワークを別に入れないと」と思う人も多いんじゃないかな、と思いますが、Goの場合は組み込みのサーバーで問題なかったりします。Node.jsに近いかも? 世間

                                    Goのおすすめのフレームワークはnet/http | フューチャー技術ブログ
                                  • SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog

                                    こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ

                                      SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
                                    • Cookie2 とは何か | blog.jxck.io

                                      Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知

                                        Cookie2 とは何か | blog.jxck.io
                                      • Deep Dive into The Go's Web Server

                                        Goのnet/httpパッケージはとてもよくできており、Webサーバーを動かすのに必要になる「httpコネクションを確立してリクエストを読んでルーティングして……」という手続き的な処理を気にせずとも誰でも簡単にWebサーバーを立てられるようになっています。 ですが、そのnet/httpが代わりにやってくれている「裏側の処理」の部分が気になる、何やっているんだろう?と不思議に思っている方はいませんか? この本では、実際に筆者がnet/httpパッケージのソースコードを読み込んだうえで、「GoのWebサーバーがどのような仕組みで起動・動いているのか」というところについて、図を使いながら解説しています。

                                          Deep Dive into The Go's Web Server
                                        • HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                          ハイクラス求人TOPIT記事一覧HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題 HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題 IETFで標準化が進められているWebの新しい通信プロトコルQUICとHTTP/3について、現在のインターネットが抱える課題やプロトコル設計での議論を中心に、ASnoKaze blogの後藤ゆき(@flano_yuki)さんに執筆いただきました。 2021年、Webに新しい通信プロトコルが登場しました。RFC 9000として標準化されたQUICと、その上で動作するHTTP/3です。HTTP/3はまだドラフト版ですが出版準備段階となっており、すでに実際のWeb通信でも広く使われています この2つのプロトコルは、現在のWebやイン

                                            HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか? 現代のプロトコル設計とインターネットの課題|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                          • Building Protocols with HTTP

                                            Workgroup: HTTP Internet-Draft: draft-ietf-httpbis-bcp56bis Obsoletes: 3205 (if approved) Published: 22 March 2022 Intended Status: Best Current Practice Expires: 23 September 2022 Author: Building Protocols with HTTP Abstract Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new applicati

                                            • SSL/TLS実践入門 ──Webの安全性を支える暗号化技術の設計思想

                                              2024年4月25日紙版発売 2024年4月25日電子版発売 市原創,板倉広明 著 A5判/456ページ 定価3,740円(本体3,400円+税10%) ISBN 978-4-297-14178-3 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 SSL/TLSは,通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており,今日のWebでは利用が一般的になっています。本書では,その最新バージョンであるTLS 1.3のしくみと,その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的

                                                SSL/TLS実践入門 ──Webの安全性を支える暗号化技術の設計思想
                                              • HTTP/1.1 Must Die

                                                HTTP/1 Must Die It's time to acknowledge HTTP/1.1 is insecure Upstream HTTP/1.1 is inherently insecure, and routinely exposes millions of websites to hostile takeover. Vendors have spent six years deploying mitigations, and researchers have consistently bypassed them. In PortSwigger's latest research, we introduce several novel classes of HTTP desync attack, and showcase critical vulnerabilities w

                                                  HTTP/1.1 Must Die
                                                • 「418 I'm a teapot」が永久欠番(?)に ~25年前の発行されたジョークRFCの後始末/【やじうまの杜】

                                                    「418 I'm a teapot」が永久欠番(?)に ~25年前の発行されたジョークRFCの後始末/【やじうまの杜】
                                                  • [アップデート]LambdaがHTTPSエンドポイントから実行可能になる、AWS Lambda Function URLsの機能が追加されました! | DevelopersIO

                                                    [アップデート]LambdaがHTTPSエンドポイントから実行可能になる、AWS Lambda Function URLsの機能が追加されました! LambdaにHTTPSエンドポイントを追加して、Webフックみたいな使い方をすることができるようになる便利なアップデートです! Lambdaを使ったWebフックが作りやすくなって、かんたんに設定できるのでぜひお試しを! Lambdaに便利なアップデートが来ました! LambdaにHTTPSエンドポイントを追加して、Webフックみたいな使い方をすることができるようになるアップデートです! AWS Lambda Function URLs: built-in HTTPS endpoints for your Lambda functions これで、ちょっとLambdaをHTTPS経由で実行したいなー。なんて時に、API Gatewayを使わずに

                                                      [アップデート]LambdaがHTTPSエンドポイントから実行可能になる、AWS Lambda Function URLsの機能が追加されました! | DevelopersIO
                                                    • 比較的安全にMCPサーバを動かす - LIFULL Creators Blog

                                                      KEELチーム の相原です。 前回のエントリは「小さい経路最適化ミドルウェアを実装してあらゆるAZ間通信を削減する」でした。 www.lifull.blog 今回は、MCPサーバを比較的安全に動かすために色々やってた話を書きたいと思います。 MCPについて MCPサーバのリスク なるべくローカルで動かさない ローカルではせめてDockerで動かす 無理やりHTTP Transportに対応する セッションの開始 コマンドの起動 ペイロードを受け取るためのエンドポイントの実装 まとめ MCPについて MCPはModel Context Protocolの略で、Anthropicが標準化を主導するLLMとその外部を繋ぐプロトコルです。 github.com これによりGitHubやPlaywrightといった外部のツールをLLMが自律的に利用できるようになり、OpenAIもサポートを表明したこ

                                                        比較的安全にMCPサーバを動かす - LIFULL Creators Blog
                                                      • フリーWi-Fiを使おうとしたらhttpのサイトを開かないと認証できないことが分かって崩れ落ちかけたが、阿部寛のホームページのおかげで接続できた

                                                        すのほ @sunoho ローソンのFree Wi-Fiが全然つながらないのであれこれ試したところ、最初にHTTPのサイトを開かないと認証ページが出てこないことがわかり、「今どきHTTPのサイトなんてねえだろ…」と崩れ落ちかけたが、阿部寛のホームページのアドレスを暗記していたため無事接続することができた。ありがとう阿部寛 2025-03-29 16:11:40

                                                          フリーWi-Fiを使おうとしたらhttpのサイトを開かないと認証できないことが分かって崩れ落ちかけたが、阿部寛のホームページのおかげで接続できた
                                                        • ログ調査基盤を構築してみた

                                                          こんにちは。 株式会社ココナラのインフラ・SREチーム所属の かず です。 システム運用において、有事の際に迅速かつ適切なシステム稼働状況の確認は欠かせません。 その手段の1つとして、ログの調査や分析の効率化は切っても切れない関係です。 システムが成長するにあわせ、ログの種類や量が多くなり、結果としてログの調査や分析が難しくなるのはよくある話かと思います。 弊社でもサービスのグロースに伴って、ログの種類や量が多くなり、結果としてログの調査や分析で課題を抱えていました。具体的には以下の2点です。 ログから原因調査を行うには、複数ログを横断・突き合わせが必要 ログの追跡に必要な情報がログに出力されない場合がある そこで、課題への対応としてログ調査基盤の構築を行いました。 本記事では背景や苦労したこと、効果についてご紹介します。 複数ログの横断調査実現に向けて ログ調査基盤の構築 苦労したこと

                                                            ログ調査基盤を構築してみた
                                                          • 【アップデート】Amazon CloudFront を経由しないアクセスのブロックが簡単になりました | DevelopersIO

                                                            ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで CloudFront の IP アドレスが Managed Prefix List でサポートされました。これにより CloudFront を経由しない不正なアクセスを簡単に弾くことが可能になります。CMS など CloudFront を使う機会が多いサービスではぜひご利用ください。また CloudFront で AWS WAF を使ってセキュリティを向上している場合の迂回路を塞ぐことができます。 Amazon CloudFront now supports a managed prefix list CloudFront を経由しないアクセス 今まで AWS で CloudFront を経由したアクセスだけ強制させる場合は、CloudFront ではカスタムヘッダを付与して、その値を ALB や Web サーバで

                                                              【アップデート】Amazon CloudFront を経由しないアクセスのブロックが簡単になりました | DevelopersIO
                                                            • Web Application開発に10080番ポートは使ってはいけない

                                                              要約 現在最新のGoogle Chormeで10080番ポートが使用できなくなった Firefoxではすでにブロック済み NAT Slipstreaming v2攻撃への対応のため ブラウザからアクセスするサーバを建てる場合は10080以外のポートにするべき 回避方法は一応ある Chrome 91以降は10080番ポートがブロックされる Google Chormeの91 (2021/05/25 リリース)から10080番ポートへのサーバに接続できなくなります。 例えば Google Chrome 90だと以下のように10080番のポートを受け付けるサーバにアクセスできますが、91以降だとアクセスできなくなります % python -m http.server 10080 Serving HTTP on 0.0.0.0 port 10080 (http://0.0.0.0:10080/) .

                                                                Web Application開発に10080番ポートは使ってはいけない
                                                              • App Engine VS Cloud Run

                                                                Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a

                                                                  App Engine VS Cloud Run
                                                                • HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog

                                                                  IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる(例えばIPアドレスが変わってもコネクションを維持できる) HTTPの認証方式をサポートする(Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme) SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス

                                                                    HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog
                                                                  • PHPで学ぶ Session の基本と応用 / web-app-session-101-2024

                                                                    PHPカンファレンス関西2024 の登壇資料です。 Cookie を使った Session 管理について解説しています。

                                                                      PHPで学ぶ Session の基本と応用 / web-app-session-101-2024
                                                                    • DNSでHTTPS ※ただしDNS over HTTPSではない

                                                                      執筆者:IIJ ネットワーク本部 アプリケーションサービス部 DNS技術課 山口 崇徳 2023年11月、HTTPSレコードがRFC9460として標準化されました。 HTTP/3を支える技術のひとつで、WebサーバのDNSへの登録方法も変わります。 CNAME + MX + α の機能も備えて…

                                                                        DNSでHTTPS ※ただしDNS over HTTPSではない
                                                                      • 「Firefox」で突如Webサイトが開けなくなる現象が発生中【19:30更新】 - 窓の杜

                                                                          「Firefox」で突如Webサイトが開けなくなる現象が発生中【19:30更新】 - 窓の杜
                                                                        • Honoの捉え方、またはNext.jsとの組み合わせ方 | stin's Blog

                                                                          HonoというWebフレームワークがあります。Express.jsのような書き方でWebアプリケーションを作れるものです。 import { Hono } from "hono"; const app = new Hono(); app.get("/", (c) => c.json({ message: "Hello, Hono!" })); export default app; HonoはWeb標準準拠を謳っているフレームワークです。それを聞くとなんだか小難しく感じます。 Web標準とは Request と Response のインスタンスを扱うということです。これらは主にブラウザ上のJavaScriptのfetch関数が取り扱うオブジェクトですね。 RequestはfetchでHTTPリクエストを送信するときに、データをまとめておくオブジェクトです。例えば送信先のURLやHTTPメソ

                                                                            Honoの捉え方、またはNext.jsとの組み合わせ方 | stin's Blog
                                                                          • WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport | RxDB - JavaScript Database

                                                                            WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport For modern real-time web applications, the ability to send events from the server to the client is indispensable. This necessity has led to the development of several methods over the years, each with its own set of advantages and drawbacks. Initially, long-polling was the only option available. It was then succeeded by Web

                                                                              WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport | RxDB - JavaScript Database
                                                                            • Cache 解体新書

                                                                              Web 技術解体新書 第二章 Cache 解体新書 Cache は Web に限らずシステム設計における最も難しいトピックの 1 つだ。 本章では、 Web における Caching の概念を `Cache-Control` だけでなく関連するあらゆる仕様の側面から解説する。 仕様は 2022/06 に公開された RFC 9111 および関連最新仕様に対応済み。 概要等は Chapter 01 [無料公開] に記載

                                                                                Cache 解体新書
                                                                              • PHPで学ぶ Session の基本と応用 / web-app-session-101

                                                                                PHPerKaigi 2021 の登壇資料です。 Cookie を使った Session 管理について解説しています。

                                                                                  PHPで学ぶ Session の基本と応用 / web-app-session-101
                                                                                • HTTP クライアントを作ろうとして学ぶ、使いやすいインタフェース / #GoCon_Sendai 2020

                                                                                  Go Conference 20' Autumn SENDAI - https://www.youtube.com/watch?v=7SdxaKurDOc - How to design a good API and why it matters https://research.google/…

                                                                                    HTTP クライアントを作ろうとして学ぶ、使いやすいインタフェース / #GoCon_Sendai 2020

                                                                                  新着記事