{"id":19521,"date":"2026-05-30T15:02:41","date_gmt":"2026-05-30T13:02:41","guid":{"rendered":"https:\/\/webhosting.de\/http-conditional-requests-cache-validierung-optimierung-paket\/"},"modified":"2026-05-30T15:02:41","modified_gmt":"2026-05-30T13:02:41","slug":"http-conditional-requests-cache-validation-optimization-package","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/http-conditional-requests-cache-validierung-optimierung-paket\/","title":{"rendered":"Understanding HTTP conditional requests and cache validation"},"content":{"rendered":"<p><strong>HTTP Conditional<\/strong> Requests reduce transmission costs by ensuring that the client only loads a resource completely if it has actually been changed since the last request. I will show how <strong>Cache validation<\/strong> with ETag, Last-Modified, If-None-Match, If-Modified-Since and 304 Not Modified works reliably and loading times are noticeably reduced.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Validation<\/strong> instead of full download: 304 saves bandwidth and time.<\/li>\n  <li><strong>ETag<\/strong> and Last-Modified work together for clean control.<\/li>\n  <li><strong>Cache control<\/strong> defines freshness, expires only supplements.<\/li>\n  <li><strong>Preconditions<\/strong> such as If-Match save write operations.<\/li>\n  <li><strong>Security<\/strong> requires private\/no-store for sensitive content.<\/li>\n<\/ul>\n\n<h2>What conditional requests do in everyday life<\/h2>\n\n<p>I set <strong>Conditional<\/strong> requests to ask the server a clear question: Do I really need to transfer new data or is my cache sufficient? The browser or a proxy sends conditions, the server checks whether a file has changed and responds with 304 Not Modified without body. This pattern keeps HTML, CSS, JavaScript, images and API responses up to date and significantly reduces the load on the infrastructure. For longer valid assets, I use long max-age values and ensure that they are up to date through validation. If you have the right <a href=\"https:\/\/webhosting.de\/en\/http-cache-control-strategies-hosting-cachemaster\/\">Cache control strategies<\/a> gets the most out of caches without risking outdated content.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/httpcache-0614.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Headers that enable cache validation<\/h2>\n\n<p>For reliable <strong>Cache<\/strong>-The client needs clear signals from the response to make decisions. I use Cache-Control for freshness and rules, Expires occasionally as a supplement, and Last-Modified and ETag for the actual validation. Last-Modified provides a modification time that can be checked quickly, while ETag provides a version identifier that is also valid for dynamic content. Important: no-cache means validate before use, not delete. If you apply these semantics correctly, you will achieve noticeably less data traffic with the same up-to-dateness of the <strong>Contents<\/strong>.<\/p>\n\n<h2>Sequence of a conditional request without detours<\/h2>\n\n<p>On the first call, the client saves the file and validation values such as <strong>ETag<\/strong> or Last-Modified in the cache. Later, the resource expires or requires a new check before use, and the client sends If-None-Match or If-Modified-Since. The server compares the information with the current status and returns either 200 OK with a new body or 304 Not Modified without payload. The client then continues to use the existing copy and saves transmission, TLS workload and time. This ping-pong seems inconspicuous, but the <strong>Effect<\/strong> on loading feel and server load is clear.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http_requests_besprechung_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag vs. Last-Modified in direct comparison<\/h2>\n\n<p>I use <strong>Last-Modified<\/strong> I like to use timestamps as a quick, simple reference, but use ETags for fine-grained control. Timestamps can reach their limits with very short change intervals or falsify dynamic outputs. I create ETags from file hashes, database versions or render variants, whereby each content change generates a new identifier. Both mechanisms can be combined: The client can send If-None-Match and If-Modified-Since in parallel, and the server selects the appropriate check. How to ensure a reliable <strong>Validation<\/strong>, which applies equally to static and dynamic resources.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterion<\/th>\n      <th>Last-Modified<\/th>\n      <th>ETag<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Accuracy<\/strong><\/td>\n      <td>Second resolution, suitable for files<\/td>\n      <td>Version identifier for each content change<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Dynamics<\/strong><\/td>\n      <td>Weak with frequent, non-file-based changes<\/td>\n      <td>Strong for APIs and rendered content<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Expenditure<\/strong><\/td>\n      <td>Low, available from the file system<\/td>\n      <td>Low to moderate, generation in app\/proxy<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Conflicts<\/strong><\/td>\n      <td>Clock deviations possible<\/td>\n      <td>Incorrectly configured weak\/strong tags possible<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Correct settings for browser caching and APIs<\/h2>\n\n<p>For static assets, I use long <strong>max-age<\/strong> and save via ETag or file name hash so that updates are recognized immediately. I often mark HTML and API responses with no-cache so that the client validates before use without having to reload everything every time. I mark personalized pages with private so that shared caches do not output anything that has been retained to others. Errors are often caused by contradictory directives or missing validation headers, which I avoid with clear rules. If you know the typical stumbling blocks, you can easily avoid them; the article on <a href=\"https:\/\/webhosting.de\/en\/http-cache-headers-sabotage-caching-cachefix\/\">Header traps in caching<\/a>, which I like to follow.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http-conditional-cache-validation-3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Using status codes and conditions effectively<\/h2>\n\n<p>I arrange <strong>Status codes<\/strong> clearly: 200 OK delivers content, 304 Not Modified confirms cache usage, and 412 Precondition Failed aborts if a condition is not met. For secure write operations, I use If-Match so that updates only take effect if the ETag corresponds to the expected version. Reading with If-None-Match or If-Modified-Since prevents superfluous payloads and keeps clients synchronized. Consistent behavior is important: The same endpoint should respond identically for identical preconditions. For SEO and bots, I pay attention to how caches and crawlers interpret status messages; a good overview of <a href=\"https:\/\/webhosting.de\/en\/http-status-codes-crawling-hosting-optimization-crawlboost\/\">HTTP status codes and crawling<\/a> helps with clean decisions.<\/p>\n\n<h2>Security and data protection for caching<\/h2>\n\n<p>I treat sensitive content with <strong>no-store<\/strong> and thus give them no chance of ending up in the browser or proxy cache. I mark personalized pages with Cache-Control: private and check that no personal data appears in long-term cached URLs. I design ETags neutrally, without allowing conclusions to be drawn about user accounts or internal IDs. I consistently deactivate all caching for login views and banking flows. If you combine data minimization, suitable directives and clean headers, you reduce risk and preserve <strong>Confidentiality<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http_cache_validierung_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Implementation: Steps for server and application<\/h2>\n\n<p>At the beginning I separate <strong>static<\/strong> of dynamic resources and decide where long deadlines make sense and where validation has priority. In Nginx, Apache or an app server, I configure cache control and activate last-modified and ETags, whereby I place the ETag generation in the application for dynamic endpoints. When processing incoming requests, I evaluate If-None-Match and If-Modified-Since and respond with 304 if the condition matches. For write operations, I use If-Match and return 412 in the event of deviations to prevent overwriting. This creates a consistent behavior that uses caches efficiently and at the same time <strong>Correctness<\/strong> ensures.<\/p>\n\n<h2>Use metrics, tests and monitoring sensibly<\/h2>\n\n<p>I check the <strong>Network<\/strong>-tab of the DevTools to check whether resources are coming from the cache, are being validated or are freshly loaded. I monitor the status, age values, ETags and the size of the transferred response. Under load, I measure latency, transfer volume and server CPU to see the actual effect of 304 responses. Logs from the reverse proxy show whether shared caches are doing their job and how many validations are successful. I use this data to adjust max-age, cache control directives and ETag strategies until response times and <strong>Hit rate<\/strong> vote.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/EntwicklerdeskCache3178.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hosting performance: Why conditional requests save money<\/h2>\n\n<p>Any <strong>304<\/strong>-The shared cache response saves bandwidth, reduces TLS overhead and shortens the response time, which is particularly important for many similar requests. In hosting setups with reverse proxies, load balancers and CDNs, I achieve the greatest effect when I clearly allow or specifically exclude shared caches. Less transfer often also means lower traffic costs in euros and more reserves for real load peaks. The user experience is also improved because repeated page views and API polls respond more quickly. In this way, I leverage performance potential that pure hardware upgrades alone cannot deliver and utilize existing <strong>Infrastructure<\/strong> better.<\/p>\n\n<h2>Common mistakes and pragmatic solutions<\/h2>\n\n<p>Contradictory <strong>Header<\/strong> like no-cache paired with expires far in the future confuse caches; I set clear rules without duplication. Missing ETags for dynamic endpoints lead to unnecessary full downloads; I add a reliable identifier and evaluate if-none-match. Too short max-age values waste potential with rarely changed files; I stretch deadlines and still secure them with validation. Aggressive caching of HTML delays visible changes; I combine no-cache with ETag and keep content up to date. With clear decisions on freshness, validation and validity, I solve these stumbling blocks and strengthen the <strong>Plannability<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/cache-validierung-5836.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Use Vary cleanly and control representations<\/h2>\n\n<p>To ensure that conditional requests work safely in shared caches, I make sure to use the correct <strong>Vary<\/strong>. The header defines which request headers influence the representation. Typical examples are <em>Accept-Encoding<\/em> (gzip, br), <em>Accept-Language<\/em> and <em>Accept<\/em>. If I deliver content per language, I set Vary: Accept-Language so that a proxy does not share the German version in response to a French request. For personalized content, I deliberately do not use Vary: Cookie and instead use <em>Cache control: private<\/em>, to avoid an uncontrollable explosion of cache keys. For resources that are only delivered with valid authorization, I either use private or ensure clear separation with Vary: Authorization or Vary on relevant headers. Consistency is important: the selected set of Vary dimensions must remain stable, otherwise the cache hit rate and validation benefits will collapse because new variants are constantly being created.<\/p>\n\n<h2>Strong vs. weak ETags, compression and byte equality<\/h2>\n\n<p><strong>Strong ETags<\/strong> identify byte-by-byte identical representations and allow precise validation, also in combination with range requests. <strong>Weak ETags<\/strong> (W\/...) only signalize content equality, not necessarily identical bytes. In practice, I use strong ETags if I can generate a unique identifier for each representation (including compression). As soon as a reverse proxy uses gzip or brotli on-the-fly, I adapt the ETag generation or switch to weak ETags so that the server and client do not mistakenly regard different bytes as identical. A robust variant is to form the ETag from the final bytes of the delivered response and at the same time to use <em>Vary: Accept-Encoding<\/em> to be set. This ensures that \u201egzip\u201c and \u201ebr\u201c each receive their own valid ETags. Where I cannot ensure byte equality (e.g. different timestamps in HTML), I choose weak ETags that still allow reliable 304 responses as long as the meaning of the page has not changed.<\/p>\n\n<h2>Cache control in fine-tuning: s-maxage, must-revalidate, stale-while-revalidate<\/h2>\n\n<p>Besides <em>max-age<\/em> I specifically use finer directives. <strong>s-maxage<\/strong> addresses exclusively <em>Shared caches<\/em> (CDNs, proxies) and allows me to cache more aggressively there than in the browser. <strong>must revalidate<\/strong> forces clients not to use expired content heuristically, but to always validate it - helpful for critical data. <strong>proxy revalidate<\/strong> addresses this obligation specifically to shared caches. With <strong>stale-while-revalidate<\/strong> I allow a slightly outdated copy to be delivered temporarily while validation is running in the background; users see something immediately, and the next request benefits from fresh metadata. <strong>stale-if-error<\/strong> as a safety net: If the origin fails or returns errors, the cache is allowed to deliver the last known copy for a defined time. For build-hashed assets, I combine long max-age with <em>immutable<\/em>, as the file name changes with the content and intermediate validations are unnecessary. For HTML and APIs, no-cache plus validator remains the gold standard to ensure up-to-dateness and still save bandwidth.<\/p>\n\n<h2>Further conditions and methods: HEAD, range and writing conflicts<\/h2>\n\n<p>Conditional requests are not limited to GET. A <strong>HEAD<\/strong>-request only provides headers and is ideal for quick validations without a body. For large files I use <strong>range<\/strong>-requests; with <strong>If-Range<\/strong> I make sure that partial areas are only sent if the resource still matches the expected version - otherwise I respond with 200 and a complete body. For write operations, I ensure consistency with <strong>If-Match<\/strong> ab: PUT, PATCH or DELETE only work if the ETag of the client matches the current version; otherwise I respond with 412 Precondition Failed. Where I want to enforce preconditions, for example with conflict-prone resources, I use 428 Precondition Required to get clients to use If-Match. I deliberately choose between 409 Conflict and 412: 412 signals violated preconditions, 409 emphasizes content conflicts (e.g. business logic rules). This clarity facilitates client implementations and avoids blind overrides.<\/p>\n\n<h2>Personalization, cookies and data protection in practice<\/h2>\n\n<p>For personalized pages, I mark answers with <strong>private<\/strong> or <strong>no-store<\/strong>. I avoid encoding user states in e-tags because such \u201eper-user\u201c e-tags can involuntarily become tracking markers. Instead, I make a strict distinction between public and private representations. I only set cookies in the cache key (Vary: Cookie) if absolutely necessary, because they increase the number of variants and dramatically reduce the hit rate. For authorized API responses I stick to <em>Cache control: private<\/em> and, if necessary, to Vary on the Authorization header format. This is how I ensure that shared caches do not inadvertently share confidential responses. In applications with mixed content (public basic framework, personalized sub-areas), I rely on fragmented caching or edge ESI\/SSI, while critical parts remain private. The result is data protection without a drop in performance.<\/p>\n\n<h2>Operation: CDNs, surrogates and invalidations<\/h2>\n\n<p>In CDN setups I combine <strong>s-maxage<\/strong> with clear validators and - if available - use surrogate-specific directives to control edge caches separately from the browser. Revalidation reduces the load on Origin, but occasionally a hard invalidation is necessary (e.g. security fix). I then plan two ways: <em>Cache busting<\/em> via file name hashes for static assets and <em>Purge<\/em>\/Invalidation for HTML and APIs. This prevents \u201epurge storms\u201c and still maintains a short time-to-freshness. It is also important to have a consistent cache key in the CDN (including host, path, query parameters and relevant Vary headers). For query parameters, I consciously differentiate between semantic (e.g. ?lang=) and purely tracking-related parameters; I ignore the latter in the cache key to avoid fragmentation. This keeps the chain of browser cache, intermediate proxy and CDN transparent and predictable.<\/p>\n\n<h2>304 in detail: Update header and metadata correctly<\/h2>\n\n<p>Also a <strong>304<\/strong>-response carries important metadata. I deliver Date, Cache-Control, ETag\/Last-Modified and - if relevant - Expires and Vary again so that the client can update its cache entries. Content-Type and Content-Encoding do not necessarily have to be repeated, but can contribute to clarity. It is important that 304 does not contain a body payload and that I send consistent validators: Changing the ETag in the 304 without changing the representation leads to confusion. If guidelines are adjusted (e.g. longer max-age), the client can adopt the metadata without having to reload the body - a small lever with a big impact on perceived performance.<\/p>\n\n<h2>Test and debug strategies for clean validation<\/h2>\n\n<p>I specifically check the following points in DevTools: <em>from disk cache<\/em> vs. <em>from memory cache<\/em> vs. <em>revalidated<\/em>; Status 200\/304; Age header in responses from shared caches; ETag\/Last-Modified consistency and the effect of Vary. For reproducible tests, I temporarily deactivate the browser cache or use a private mode. On the server side, I evaluate logs on the 200\/304 ratio, the average response size and CPU utilization. Warning signals are, for example, many 200 responses to resources with short change intervals (missing validators), revalidation loops (deviating times\/clock drift) or an unusually large number of variants per URL (excessive Vary). I use load tests to check how s-maxage, stale-while-revalidate and if-none-match behave under pressure - and adjust directives until throughput and latency match.<\/p>\n\n<h2>Edge cases and robust defaults<\/h2>\n\n<p>Not every resource has clear change rules. I set careful defaults for generated sitemaps, feeds or dashboards: <em>no-cache<\/em> plus ETag\/Last-Modified. With unstable clocks between upstream systems, I avoid rigid second comparisons and prefer ETags that are independent of timestamps. If compression is variable (different gzip levels), I include the result of the compression in the ETag generation or switch to weak ETags. And if clients request without validators, I send clear signals: Either clear freshness (max-age\/immutable) or clear validation (no-cache + ETag). These <em>robust defaults<\/em> ensure that even incomplete or faulty clients do not trigger any unwanted load peaks.<\/p>\n\n<h2>Brief summary<\/h2>\n\n<p>Connect conditional requests <strong>Speed<\/strong> and timeliness by having clients only retrieve complete resources when content has changed. I use cache control for freshness, combine last-modified and ETag for reliable checks and consistently respond with 304 if conditions are met. I isolate personalized and confidential content with private or no-store so that no data ends up in shared caches. Measurements in DevTools, logs and metrics show me where I can stretch deadlines or sharpen validation logic. If you think about these building blocks together, you will achieve faster pages, reduced server load and a <strong>rounder<\/strong> User experience without wasting data.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how HTTP Conditional Requests and cache validation with ETag, Last-Modified and Cache-Control optimize your browser caching and increase performance.<\/p>","protected":false},"author":1,"featured_media":19514,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-19521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"83","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"HTTP Conditional","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19514","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=19521"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19521\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19514"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}