OiO.lk Community platform!

Oio.lk is an excellent forum for developers, providing a wide range of resources, discussions, and support for those in the developer community. Join oio.lk today to connect with like-minded professionals, share insights, and stay updated on the latest trends and technologies in the development field.
  You need to log in or register to access the solved answers to this problem.
  • You have reached the maximum number of guest views allowed
  • Please register below to remove this limitation

Why doesn’t the ASGI specification allow handshake rejection with custom reason?

  • Thread starter Thread starter Chukwujiobi Canon
  • Start date Start date
C

Chukwujiobi Canon

Guest
A client initially opens a connection to an ASGI compliant server. The server forwards a Connect event [asgi-spec] to the application. This event must be responded to with either an Accept event [asgi-spec] or a Close event. [asgi-spec] The server must send this event during the handshake phase of the WebSocket and not complete the handshake until it gets a reply.

If the application responds with a Close event, the server must close the connection with a HTTP 403 status code and not complete the WebSocket handshake.



Why simply 403? Not even a reason key is allowed to be part of the event responded. Just 403. You would expect that it is during handshake that Authentication would be done hence a possible 401.

The WebSocket Protocol specification allows any HTTP status code besides 101.

Any status code other than 101 indicates that the WebSocket handshake has not completed and that the semantics of HTTP still apply.

What is the rationale behind ASGI’s specification?
<p>A client initially opens a connection to an ASGI compliant server. The server forwards a <a href="https://asgi.readthedocs.io/en/latest/specs/www.html#connect-receive-event" rel="nofollow noreferrer"><code>Connect event</code> <sup>[asgi-spec]</sup></a> to the application. This event must be responded to with either an <a href="https://asgi.readthedocs.io/en/latest/specs/www.html#accept-send-event" rel="nofollow noreferrer"><code>Accept event</code> <sup>[asgi-spec]</sup></a> or a <a href="https://asgi.readthedocs.io/en/latest/specs/www.html#close-send-event" rel="nofollow noreferrer"><code>Close event</code>. <sup>[asgi-spec]</sup></a> The server must send this event during the <em>handshake phase</em> of the WebSocket and <em><strong>not</strong></em> complete the handshake until it gets a reply.</p>
<p>If the application responds with a <code>Close event</code>, the server <em><strong>must</strong></em> close the connection with a HTTP <code>403</code> status code and not complete the WebSocket handshake.</p>
<hr/>
<p>Why simply <code>403</code>? Not even a reason key is allowed to be part of the event responded. Just <code>403</code>. You would expect that it is during <em>handshake</em> that <em>Authentication</em> would be done hence a possible <code>401</code>.</p>
<p>The WebSocket Protocol specification allows any HTTP status code besides <code>101</code>.</p>
<blockquote>
<p>Any status code other than <code>101</code> indicates that the WebSocket handshake has not completed and that <em><strong>the semantics of HTTP still apply</strong></em>.</p>
</blockquote>
<p>What is the rationale behind ASGI’s specification?</p>
 

Latest posts

Top