Skip to content
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

Merged
merged 15 commits into from
May 22, 2024
Merged

Conversation

elf-pavlik
Copy link
Contributor

πŸ“ 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

  • this PR is labeled with the correct semver label
    • semver.patch: Backwards compatible bug fixes.
    • semver.minor: Backwards compatible feature additions.
    • semver.major: Breaking changes. This includes changing interfaces or configuration behaviour.
  • the correct branch is targeted. Patch updates can target main, other changes should target the latest versions/* branch.
  • the RELEASE_NOTES.md document in case of relevant feature or config changes.
  • any relevant documentation was updated to reflect the changes in this PR.

Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
@elf-pavlik elf-pavlik changed the title StremingHTTPChannel2023 StreamingHTTPChannel2023 Apr 3, 2024
Copy link
Member

@joachimvh joachimvh left a 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.

Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
Co-authored-by: Maciej Samoraj <maciej.samoraj@gmail.com>
@elf-pavlik elf-pavlik marked this pull request as ready for review April 26, 2024 02:04
Copy link
Contributor

@TallTed TallTed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo, grammar, punctuation...

documentation/markdown/usage/notifications.md Outdated Show resolved Hide resolved
documentation/markdown/usage/notifications.md Outdated Show resolved Hide resolved
documentation/markdown/usage/notifications.md Outdated Show resolved Hide resolved
documentation/markdown/usage/notifications.md Outdated Show resolved Hide resolved
documentation/markdown/usage/notifications.md Outdated Show resolved Hide resolved
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
@elf-pavlik
Copy link
Contributor Author

When the client disconnects from the streaming response, the following gets logged.

[BasicResponseWriter] {Primary} error: Aborting streaming response because of server error; headers already sent.
[BasicResponseWriter] {Primary} error: Response error: premature close
[HandlerServerConfigurator] {Primary} error: Request error: aborted

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?

@joachimvh
Copy link
Member

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>
Copy link
Member

@joachimvh joachimvh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly minor issues

config/http/notifications/all.json Outdated Show resolved Hide resolved
config/http/notifications/streaming-http.json Outdated Show resolved Hide resolved
config/http/notifications/streaming-http/http.json Outdated Show resolved Hide resolved
config/http/notifications/streaming-http/http.json Outdated Show resolved Hide resolved
config/http/notifications/streaming-http/http.json Outdated Show resolved Hide resolved
test/integration/StreamingHttpChannel2023.test.ts Outdated Show resolved Hide resolved
test/integration/StreamingHttpChannel2023.test.ts Outdated Show resolved Hide resolved
test/integration/StreamingHttpChannel2023.test.ts Outdated Show resolved Hide resolved
test/util/Util.ts Outdated Show resolved Hide resolved
const del = await fetch(receiveFrom, {
method: 'DELETE',
});
expect(del.status).toBe(404);
Copy link
Contributor Author

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" ]

Copy link
Member

@joachimvh joachimvh May 15, 2024

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.

Copy link
Contributor Author

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?

Copy link
Member

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?

I have no idea tbh, would be something to investigate πŸ˜…

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

@elf-pavlik elf-pavlik requested a review from joachimvh May 14, 2024 23:36
@elf-pavlik
Copy link
Contributor Author

If all your feedback is addressed, I could

  • wait for update CI node versionsΒ #1906 and rebase this branch
  • remove undici and workaround that times out the response body in the integration test
  • squash everything into a single commit?

@joachimvh
Copy link
Member

joachimvh commented May 15, 2024

If all your feedback is addressed, I could

  • wait for update CI node versions #1906 and rebase this branch

  • remove undici and workaround that times out the response body in the integration test

  • squash everything into a single commit?

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.

@joachimvh
Copy link
Member

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?

@elf-pavlik
Copy link
Contributor Author

All your suggestions should be addressed now. Thank you for all the help!

Copy link
Member

@joachimvh joachimvh left a 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>
@elf-pavlik elf-pavlik requested a review from joachimvh May 21, 2024 12:10
Copy link
Member

@joachimvh joachimvh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good ^^

@joachimvh joachimvh merged commit cb38613 into CommunitySolidServer:main May 22, 2024
37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Notifications] support for StreamingHTTPChannel2023
3 participants