{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "item": { "id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "slug": "reapply-complete-axis-event-filters-after-a-websocket-reconnect", "url": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect.md", "json": "https://update.dsesecurity.com/api/v1/posts/reapply-complete-axis-event-filters-after-a-websocket-reconnect/" }, "title": "Reapply complete Axis event filters after a WebSocket reconnect", "summary": "Axis event WebSocket sessions cannot continue after their connection ends, and only the latest event filter applies. Rebuild the intended subscription after reconnecting.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T00:10:16+00:00", "modified_at": "2026-10-29T00:10:34+00:00", "reviewed_on": "2026-10-28", "reading_minutes": 3, "word_count": 500, "potentially_affected": "Axis devices exposing the documented Event streaming over WebSocket interface; confirm support and the installed API/software scope before applying the proposed checks.", "dse_recommendation": "DSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.", "primary_source": { "name": "Axis Communications — Event streaming over WebSocket", "url": "https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/", "published_on": null, "authority": "Axis Communications" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session.

\n

Source fact: documented behavior

\n

The Event streaming over WebSocket documentation says each connection is a separate session that ends when the connection terminates.

\n

Those sessions are stateless and cannot continue after connection termination.

\n

Sending a new configuration request updates the event filter, and only the latest filter applies.

\n

What the source does not establish

\n

Do not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n

DSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.

\n
    \n
  1. Write the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready.
    2. \n
  2. Use proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active.
    3. \n
  3. In an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately.
    4. \n
\n

Verification and evidence

\n

Retain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration.

\n

Include a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee.

\n

Official references

\n\n

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.

\n", "content_text": "Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session.\nSource fact: documented behavior\nThe Event streaming over WebSocket documentation says each connection is a separate session that ends when the connection terminates.\nThose sessions are stateless and cannot continue after connection termination.\nSending a new configuration request updates the event filter, and only the latest filter applies.\nWhat the source does not establish\nDo not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article.\nApplicability questions\n\nWhere does the integration retain its complete intended event filter?\nWhich component sends and verifies subscription configuration after reconnecting?\nDoes a filter update contain the full desired selection or only an assumed addition?\nHow will operators recognize an interval when event coverage has not been established?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.\n\nWrite the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready.\nUse proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active.\nIn an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately.\n\nVerification and evidence\nRetain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration.\nInclude a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee.\nOfficial references\n\nEvent streaming over WebSocket — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "content_markdown": "Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session.\n\n## Source fact: documented behavior\n\nThe [Event streaming over WebSocket](https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/) documentation says each connection is a separate session that ends when the connection terminates.\n\nThose sessions are stateless and cannot continue after connection termination.\n\nSending a new configuration request updates the event filter, and only the latest filter applies.\n\n## What the source does not establish\n\nDo not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article.\n\n## Applicability questions\n\n- Where does the integration retain its complete intended event filter?\n\n- Which component sends and verifies subscription configuration after reconnecting?\n\n- Does a filter update contain the full desired selection or only an assumed addition?\n\n- How will operators recognize an interval when event coverage has not been established?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.\n\n- Write the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready.\n\n- Use proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active.\n\n- In an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately.\n\n## Verification and evidence\n\nRetain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration.\n\nInclude a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee.\n\n## Official references\n\n- [Event streaming over WebSocket](https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/) — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "url": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Reapply complete Axis event filters after a WebSocket reconnect", "item": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/#article", "identifier": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "url": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/", "headline": "Reapply complete Axis event filters after a WebSocket reconnect", "description": "Axis event WebSocket sessions cannot continue after their connection ends, and only the latest event filter applies.", "abstract": "Axis event WebSocket sessions cannot continue after their connection ends, and only the latest event filter applies. Rebuild the intended subscription after reconnecting.", "articleBody": "Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session.\nSource fact: documented behavior\nThe Event streaming over WebSocket documentation says each connection is a separate session that ends when the connection terminates.\nThose sessions are stateless and cannot continue after connection termination.\nSending a new configuration request updates the event filter, and only the latest filter applies.\nWhat the source does not establish\nDo not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article.\nApplicability questions\n\nWhere does the integration retain its complete intended event filter?\nWhich component sends and verifies subscription configuration after reconnecting?\nDoes a filter update contain the full desired selection or only an assumed addition?\nHow will operators recognize an interval when event coverage has not been established?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.\n\nWrite the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready.\nUse proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active.\nIn an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately.\n\nVerification and evidence\nRetain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration.\nInclude a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee.\nOfficial references\n\nEvent streaming over WebSocket — Axis Communications; official VAPIX documentation.\n\nSource review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.", "datePublished": "2026-10-29T00:10:16+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/reapply-complete-axis-event-filters-after-a-websocket-reconnect/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Reapply complete Axis event filters after a WebSocket reconnect" }, "articleSection": [ "Networks & Infrastructure", "Video Surveillance" ], "keywords": [ "Networks & Infrastructure", "Video Surveillance", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "Thing", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "wordCount": 500, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Axis Communications — Event streaming over WebSocket", "url": "https://developer.axis.com/vapix/network-video/event-streaming-over-websocket/" } } ] } }