-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
StreamingHTTPChannel2023 #1878
StreamingHTTPChannel2023 #1878
Conversation
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a quick look. The idea seems fine, just requires some cleanup.
src/server/notifications/StreamingHTTPChannel2023/StreamingHTTPListeningActivityHandler.ts
Outdated
Show resolved
Hide resolved
src/server/notifications/StreamingHTTPChannel2023/StreamingHTTP2023Emitter.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
c6ee114
to
de0ea45
Compare
bdea4bd
to
e8c00f4
Compare
src/server/notifications/StreamingHttpChannel2023/StreamingHttp2023Emitter.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo, grammar, punctuation...
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
When the client disconnects from the streaming response, the following gets logged.
I see it as normal behavior for the client to disconnect once they want to stop receiving notifications. It can also happen on a spotty connection. Should it be logged out as an error? |
You could attach an error listener to catch that one and emit a more detailed/correct error instead, but if this is only on disconnect this is not a big issue. |
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly minor issues
test/unit/server/notifications/StreamingHttpChannel2023/StreamingHttp2023Util.test.ts
Outdated
Show resolved
Hide resolved
const del = await fetch(receiveFrom, { | ||
method: 'DELETE', | ||
}); | ||
expect(del.status).toBe(404); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why DELETE
responds with 404
instead of 405
, OperationRouteHandler
has "allowedMethods": [ "GET" ]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the RouterHandler
does all its checks in the canHandle
call instead of the handle
call. Which means that if it throws an error the server will just try the next handlers until it finds one that can handle it. The last one, the LDP handler, can always handle a request and will then throw a 404 because it can't find that resource.
There is indeed something to be said for the fact that method checks should be done in the handle
call instead so a 405 is returned, but that is out of scope for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And why does only the DELETE
method respond with 404
, while HEAD,
PUT,
and POST
all respond with 405
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And why does only the
DELETE
method respond with404
, whileHEAD,
PUT,
andPOST
all respond with405
?
I have no idea tbh, would be something to investigate π
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you like, I could create an issue to track it after this PR gets merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
If all your feedback is addressed, I could
|
You can already update this PR as if the other one is merged so undici can be removed. Squashing is not necessary as I can do that when merging the PR myself. |
One other thing I just thought of, could you also update the documentation at https://communitysolidserver.github.io/CommunitySolidServer/latest/architecture/features/notifications/ with some explanation about how the architecture of this one differs from the others? |
3d050cc
to
eb3cdf5
Compare
All your suggestions should be addressed now. Thank you for all the help! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor documentation comments, after this it can be merged.
Co-authored-by: Joachim Van Herwegen <joachimvh@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good ^^
π Related issues
closes #1574
βοΈ Description
Initial commit only supports pre-established notification channels advertised in the HTTP Link header.
We will start writing tests after the initial feedback.
β PR check list
Before this pull request can be merged, a core maintainer will check whether