#2022#2021

小知识

--- title: 小知识 date: 2022-06-13 author: powerfulyang updateBy: id: 1 public: false tags: - iPhone - 投屏 --- 1. iPhone 如何简单投屏到 Mac ![source protected](14)
powerfulyangMon, Jun 13, 2022 10:36 AM

Docker 相关

--- title: Docker 相关 author: powerfulyang date: 2022-07-21 tags: - docker --- ## No colorized output 日志突然就木有颜色了。 ANSI codes has been removed. > Relate to https://github.com/docker/compose/issues/2231#issuecomment-165137408 **Try adding `tty: true` to the service config.** ```yaml qa.powerfulyang.com: image: powerfulyang/qa.powerfulyang.com container_name: qa.powerfulyang.com restart: always command: npm run start env_file: - ./qa.powerfulyang.com/.env tty: true logging: driver: gelf options: gelf-address: udp://localhost:12201 networks: - default - public ```
powerfulyangFri, Jun 10, 2022 3:18 PM

如何友好的测试 webview

--- title: 如何友好的测试 webview author: powerfulyang date: 2022-06-09 tags: - Fiddler - Charles - webview --- 外部 APP 使用 webview 加载我方 web 程序, 一些兼容性 BUG 难以调试。 可以借助抓包工具修改 response 来达到调试的目的。 主要针对 iOS 平台,为什么呢 - 当然要感谢万能的 Safari。 ## Fiddler 1. Download Fiddler Classic 仅支持 Windows。 2. 主要目的是抓取并修改 HTTPS 请求。 3. ## Charles 1. 安装 Charles 2. ![source protected](13)
powerfulyangThu, Jun 9, 2022 4:04 PM

elasticsearch 指南

--- title: elasticsearch 指南 date: 2022-06-08 tags: - es --- ## 去重 类似于 distinct 去重的字段不能是 text 类型。所以,mapping 要有 keyword。 ```HTTP POST /logstash-*/_search { index: 'logstash-*', query: { match_all: {}, }, collapse: { field: 'container_name.keyword', }, } ```
powerfulyangWed, Jun 8, 2022 4:26 PM

浏览器缓存

--- title: 浏览器缓存 date: 2022-05-26 tags: - 浏览器缓存 --- > 前端页面和资源是否被浏览器缓存,一般是由服务器通过设置 http 响应头部去告诉浏览器的。响应头是有两对相关联的头的,一个是 HTTP/1.0 的 Expires 和 Last-Modified,另一对是 HTTP/1.1 增加的 Cache-Control 和 Etag。 ## [Cache directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#cache_directives "Permalink to Cache directives") The following table lists the standard `Cache-Control` directives: | Request | Response | | --- | --- | | `max-age` | `max-age` | | `max-stale` | \- | | `min-fresh` | \- | | \- | `s-maxage` | | `no-cache` | `no-cache` | | `no-store` | `no-store` | | `no-transform` | `no-transform` | | `only-if-cached` | \- | | \- | `must-revalidate` | | \- | `proxy-revalidate` | | \- | `must-understand` | | \- | `private` | | \- | `public` | | \- | `immutable` | | \- | `stale-while-revalidate` | | `stale-if-error` | `stale-if-error` | Note: Check the [compatibility table](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#browser_compatibility) for their support; user agents that don't recognize them should ignore them. This section lists directives that affect caching — both response directives and request directives. ### [Response Directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#response_directives "Permalink to Response Directives") #### `max-age` The `max-age=N` response directive indicates that the response remains [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) until *N* seconds after the response is generated. Cache-Control: max-age=604800 Indicates that caches can store this response and reuse it for subsequent requests while it's [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness). Note that `max-age` is not the elapsed time since the response was received; it is the elapsed time since the response was generated on the origin server. So if the other cache(s) — on the network route taken by the response — store the response for 100 seconds (indicated using the `Age` response header field), the browser cache would deduct 100 seconds from its [freshness lifetime](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness_lifetime). Cache-Control: max-age=604800 Age: 100 #### `s-maxage` The `s-maxage` response directive also indicates how long the response is [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) for (similar to `max-age`) — but it is specific to shared caches, and they will ignore `max-age` when it is present. Cache-Control: s-maxage=604800 #### `no-cache` The `no-cache` response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server. Cache-Control: no-cache If you want caches to always check for content updates while reusing stored content, `no-cache` is the directive to use. It does this by requiring caches to revalidate each request with the origin server. Note that `no-cache` does not mean "don't cache". `no-cache` allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then `no-store` is the directive to use. #### `must-revalidate` The `must-revalidate` response directive indicates that the response can be stored in caches and can be reused while [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness). If the response becomes [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness), it must be validated with the origin server before reuse. Typically, `must-revalidate` is used with `max-age`. Cache-Control: max-age=604800, must-revalidate HTTP allows caches to reuse [stale responses](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) when they are disconnected from the origin server. `must-revalidate` is a way to prevent this from happening - either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated. #### `proxy-revalidate` The `proxy-revalidate` response directive is the equivalent of `must-revalidate`, but specifically for shared caches only. #### `no-store` The `no-store` response directive indicates that any caches of any kind (private or shared) should not store this response. Cache-Control: no-store #### `private` The `private` response directive indicates that the response can be stored only in a private cache (e.g. local caches in browsers). Cache-Control: private You should add the `private` directive for user-personalized content, especially for responses received after login and for sessions managed via cookies. If you forget to add `private` to a response with personalized content, then that response can be stored in a shared cache and end up being reused for multiple users, which can cause personal information to leak. #### `public` The `public` response directive indicates that the response can be stored in a shared cache. Responses for requests with `Authorization` header fields must not be stored in a shared cache; however, the `public` directive will cause such responses to be stored in a shared cache. Cache-Control: public In general, when pages are under Basic Auth or Digest Auth, the browser sends requests with the `Authorization` header. This means that the response is access-controlled for restricted users (who have accounts), and it's fundamentally not shared-cacheable, even if it has `max-age`. You can use the `public` directive to unlock that restriction. Cache-Control: public, max-age=604800 Note that `s-maxage` or `must-revalidate` also unlock that restriction. If a request doesn't have an `Authorization` header, or you are already using `s-maxage` or `must-revalidate` in the response, then you don't need to use `public`. #### `must-understand` The `must-understand` response directive indicates that a cache should store the response only if it understands the requirements for caching based on status code. `must-understand` should be coupled with `no-store` for fallback behavior. Cache-Control: must-understand, no-store If a cache doesn't support `must-understand`, it will be ignored. If `no-store` is also present, the response isn't stored. If a cache supports `must-understand`, it stores the response with an understanding of cache requirements based on its status code. #### `no-transform` Some intermediaries transform content for various reasons. For example, some convert images to reduce transfer size. In some cases, this is undesirable for the content provider. `no-transform` indicates that any intermediary (regardless of whether it implements a cache) shouldn't transform the response contents. Note: [Google's Web Light](https://developers.google.com/search/docs/advanced/mobile/web-light?visit_id=637855965115455923-776951611&rd=1) is one kind of such an intermediary. It converts images to minimize data for a cache store or slow connection and supports `no-transform` as an opt-out option. #### `immutable` The `immutable` response directive indicates that the response will not be updated while it's [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness). Cache-Control: public, max-age=604800, immutable A modern best practice for static resources is to include version/hashes in their URLs, while never modifying the resources — but instead, when necessary, *updating* the resources with newer versions that have new version-numbers/hashes, so that their URLs are different. That's called the **cache-busting** pattern. <script src=https://example.com/react.0.0.0.js></script> When a user reloads the browser, the browser will send conditional requests for validating to the origin server. But it's not necessary to revalidate those kinds of static resources even when a user reloads the browser, because they're never modified. `immutable` tells a cache that the response is immutable while it's [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) and avoids those kinds of unnecessary conditional requests to the server. When you use a cache-busting pattern for resources and apply them to a long `max-age`, you can also add `immutable` to avoid revalidation. #### `stale-while-revalidate` The `stale-while-revalidate` response directive indicates that the cache could reuse a stale response while it revalidates it to a cache. Cache-Control: max-age=604800, stale-while-revalidate=86400 In the example above, the response is [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) for 7 days (604800s). After 7 days it becomes [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness), but the cache is allowed to reuse it for any requests that are made in the following day (86400s), provided that they revalidate the response in the background. Revalidation will make the cache be [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) again, so it appears to clients that it was always [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) during that period — effectively hiding the latency penalty of revalidation from them. If no request happened during that period, the cache became [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) and the next request will revalidate normally. #### `stale-if-error` The `stale-if-error` response directive indicates that the cache can reuse a [stale response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) when an origin server responds with an error (500, 502, 503, or 504). Cache-Control: max-age=604800, stale-if-error=86400 In the example above, the response is [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) for 7 days (604800s). After 7 days it becomes [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness), but it can be used for an extra 1 day (86400s) if the server responds with an error. After a period of time, the stored response became [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) normally. This means that the client will receive an error response as-is if the origin server sends it. ### [Request Directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#request_directives "Permalink to Request Directives") #### [`no-cache`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-cache_2 "Permalink to no-cache") The `no-cache` request directive asks caches to validate the response with the origin server before reuse. Cache-Control: no-cache `no-cache` allows clients to request the most up-to-date response even if the cache has a [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) response. Browsers usually add `no-cache` to requests when users are **force reloading** a page. #### [`no-store`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-store_2 "Permalink to no-store") The `no-store` request directive allows a client to request that caches refrain from storing the request and corresponding response — even if the origin server's response could be stored. Cache-Control: no-store Note that the major browsers do not support requests with `no-store`. #### [`max-age`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#max-age_2 "Permalink to max-age") The `max-age=N` request directive indicates that the client allows a stored response that is generated on the origin server within *N* seconds — where *N* may be any non-negative integer (including `0`). Cache-Control: max-age=3600 In the case above, if the response with `Cache-Control: max-age=604800` was generated more than 3 hours ago (calculated from `max-age` and the `Age` header), the cache couldn't reuse that response. Many browsers use this directive for **reloading**, as explained below. Cache-Control: max-age=0 `max-age=0` is a workaround for `no-cache`, because many old (HTTP/1.0) cache implementations don't support `no-cache`. Recently browsers are still using `max-age=0` in "reloading" — for backward compatibility — and alternatively using `no-cache` to cause a "force reloading". If the `max-age` value isn't non-negative (for example, `-1`) or isn't an integer (for example, `3599.99`), then the caching behavior is undefined. However, the [Calculating Freshness Lifetime](https://httpwg.org/specs/rfc7234.html#calculating.freshness.lifetime) section of the HTTP specification states: > Caches are encouraged to consider responses that have invalid freshness information to be stale. In other words, for any `max-age` value that isn't an integer or isn't non-negative, the caching behavior that's encouraged is to treat the value as if it were `0`. #### [`max-stale`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#max-stale "Permalink to max-stale") The `max-stale=N` request directive indicates that the client allows a stored response that is [stale](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) within *N* seconds. Cache-Control: max-stale=3600 In the case above, if the response with `Cache-Control: max-age=604800` was generated more than 3 hours ago (calculated from `max-age` and the `Age` header), the cache couldn't reuse that response. Clients can use this header when the origin server is down or too slow and can accept cached responses from caches even if they are a bit old. Note that the major browsers do not support requests with `max-stale`. #### [`min-fresh`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#min-fresh "Permalink to min-fresh") The `min-fresh=N` request directive indicates that the client allows a stored response that is [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) for at least *N* seconds. Cache-Control: min-fresh=600 In the case above, if the response with `Cache-Control: max-age=3600` was stored in caches 51 minutes ago, the cache couldn't reuse that response. Clients can use this header when the user requires the response to not only be [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness), but also requires that it won't be updated for a period of time. Note that the major browsers do not support requests with `min-fresh`. #### [`no-transform`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-transform_2 "Permalink to no-transform") Same meaning that `no-transform` has for a response, but for a request instead. #### [`only-if-cached`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#only-if-cached "Permalink to only-if-cached") The client indicates that cache should obtain an already-cached response. If a cache has stored a response, it's reused. ## [Use Cases](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#use_cases "Permalink to Use Cases") ### [Preventing storing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_storing "Permalink to Preventing storing") If you don't want a response stored in caches, use the `no-store` directive. ``` Cache-Control: no-store ``` Note that `no-cache` means "it can be stored but don't reuse before validating" — so it's not for preventing a response from being stored. ``` Cache-Control: no-cache ``` In theory, if directives are conflicted, the most restrictive directive should be honored. So the example below is basically meaningless because `private`, `no-cache`, `max-age=0` and `must-revalidate` conflict with `no-store`. ``` # conflicted Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate # equivalent to Cache-Control: no-store ``` ### [Up-to-date contents always](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#up-to-date_contents_always "Permalink to Up-to-date contents always") For content that's generated dynamically, or that's static but updated often, you want a user to always receive the most up-to-date version. If you don't add a `Cache-Control` header because the response is not intended to be cached, that could cause an unexpected result. Cache storage is allowed to cache it heuristically — so if you have any requirements on caching, you should always indicate them explicitly, in the `Cache-Control` header. Adding `no-cache` to the response causes revalidation to the server, so you can serve a [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) response every time — or if the client already has a new one, just respond `304 Not Modified`. Cache-Control: no-cache Most HTTP/1.0 caches don't support `no-cache` directives, so historically `max-age=0` was used as a workaround. But only `max-age=0` could cause a [stale response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) to be reused when caches disconnected from the origin server. `must-revalidate` addresses that. That's why the example below is equivalent to `no-cache`. Cache-Control: max-age=0, must-revalidate But for now, you can simply use `no-cache` instead. ### [Clearing an already-stored cache](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#clearing_an_already-stored_cache "Permalink to Clearing an already-stored cache") Unfortunately, there are no cache directives for clearing already-stored responses from caches. Imagine that clients/caches store a [fresh](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#freshness) response for a path, with no request flight to the server. There is nothing a server could do to that path. Alternatively, `Clear-Site-Data` can clear a browser cache for a site. But be careful: that clears every stored response for a site — and only in browsers, not for a shared cache. ## 启发式缓存 > https://stackoverflow.com/a/27972908 如果一个可以缓存的请求没有设置 Expires 和 Cache-Control,但是响应头有设置 Last-Modified 信息,这种情况下浏览器会有一个默认的缓存策略:(当前时间 - Last-Modified) * 0.1,这就是启发式缓存。 启发式缓存是强缓存,不过期就不会走 HTTP 请求。 No explicit HTTP Cache Lifetime information was provided. Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date. **解决办法: Cache-Control: no-cache** `no-cache` The `no-cache` response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server. Cache-Control: no-cache If you want caches to always check for content updates while reusing stored content, `no-cache` is the directive to use. It does this by requiring caches to revalidate each request with the origin server. Note that `no-cache` does not mean "don't cache". `no-cache` allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then `no-store` is the directive to use. **当然这不是一个好的办法,from memory cache, 即页面打开很久没有关闭的情况,这个时候如果文件名没有改变,会直接从内存中读取。导致浏览的依然是历史版本。**
powerfulyangTue, Jun 7, 2022 6:45 PM

测试一下

--- title: 测试一下 author: powerfulyang date: 2022-04-09 tags: - test - 测试 --- ## 测试发布 哈哈哈哈哈 `sdjksndjkalsndjkasndkalndjaskndjkansdjkalsndjkasndajksndkjasdnasdkj`
powerfulyangSat, Apr 9, 2022 6:19 PM