TL;DRInstead of purely relying on URL-based pattern matching, also consider leveraging the lesser-known — but super useful — Request.destination property in your service worker to determine the type and/or caching strategy of requests. Note, though, that Request.destination gets set to the non-informative empty string default value for XMLHttpRequest or fetch() calls. You can play with the Request
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
*"If you stream it, you can do it" -- Walt Disney[^1] * Streams are trickling into the scene as we search for ways to improve performance. What if instead of waiting for our entire ajax response to complete, we could start showing the data as it arrives? Streams allow us to do this. They are a data source that can be created and processed incrementally. This means as chunks of data become availabl
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message By setting the keepalive flag, a developer can make a fetch which will continue working even when a frame is detached. A web developer can use the feature to report events, state updates and analytics with small amount of data even when the page is about to be unl
はじめまして、ひらのです。Blink 上でネットワーク関連の API (XHR, fetch API, WebSocket, …) の実装や、ローディング関連の実装を行っています。 本稿では、Fetch API における Request および RequestInit の keepalive プロパティの実装について解説します。このプロパティの実装は、Chromium のリソースローディングパスのかなりトリッキーな既存実装をいじる必要があり、また、Chromium のマルチプロセスアーキテクチャを意識することも必要なため、(いわゆる下位レイヤーですでに実装されているスイッチに配線するだけの実装と違い) 楽しい実装です。 リンク集 本稿では仕様の説明はほとんど行いません。以下を参照ください。 Fetch Spec (fetch, CORS) SendBeacon Content Securi
WHATWG, Fetch詳しくないので間違いがあればご指摘下さい Content Security Policy(CSP)やHPKPやExpect-CTでは、ユーザエージェントはセキュリティの違反を検出した際に、指定したURLにレポートを送信できる。 例えば、下記のようにHTTPレスポンスヘッダにreport-uriでレポート先を指定します (詳細は それぞれの仕様及び、Reporting APIの仕様を参照)。 Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/expect-ct: enforce;max-age=3600;report-uri=https://example.com/report-uri もちろん、ブラウザが今開いてるURLとは別ドメインのURL
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
The original GitHub issue for "Aborting a fetch" was opened in 2015. Now, if I take 2015 away from 2017 (the current year), I get 2. This demonstrates a bug in maths, because 2015 was in fact "forever" ago. 2015 was when we first started exploring aborting ongoing fetches, and after 780 GitHub comments, a couple of false starts, and 5 pull requests, we finally have abortable fetch landing in brows
Intro 以前、本ブログでも紹介した Foreign Fetch が、仕様から削除される方向で進んでいる。 Foreign Fetch による Micro Service Workers | blog.jxck.io これは、 Safari などが進めている Cookie の double keying が影響しているらしいので、現状についてまとめる。 Foreign Fetch Foreign Fetch は、簡単に言えば 3rd Party Origin の Service Worker が、その Origin に向けた Fetch をハンドルできるようにするという仕様である。 これによって、 Origin 単位での Service Worker の責務が分離できるため、以下のような設計が期待できた。 サブドメインごとに SW の責務を分離でき、更新などのライフライクルを変えられる
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message Standards: https://dom.spec.whatwg.org/#aborting-ongoing-activities https://github.com/whatwg/fetch/pull/523 Summary: In bug 1378342 I have been working on Abort API and its integration with Fetch API. There are 2 separate prefs: dom.abortController.enabled and do
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
When Fetch API became standard I was thrilled. I will no longer need to use http utility libraries in order to make http calls in my apps. XMLHttpRequest was so low level and awkward (up to its inconsistent camel casing of acronyms!). You didn’t really have a choice but to wrap it with something more comfortable or choose one of tons of open source alternatives like jQuery’s $.ajax(), Angular’s $h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く