-
Notifications
You must be signed in to change notification settings - Fork 293
Route requests more like a normal web server #1539
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
Conversation
70498dd
to
ab5d83d
Compare
This is ready for review and can merge after #1531. |
// so the service worker knows it can issue a real fetch() to the server. | ||
return new PHPResponse( | ||
404, | ||
{ 'x-file-type': ['static'] }, |
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.
That's a good opportunity to rename this to more clearly communicate the intention. Perhaps 'x-file-source': 'remote-server'
, 'x-backfill-from': 'remote-host'
, something similar?
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.
That's a good opportunity to rename this to more clearly communicate the intention. Perhaps 'x-file-source': 'remote-server', 'x-backfill-from': 'remote-host', something similar?
@adamziel Is it OK for us to leave this magic header as-is for now? I made the update but quickly discovered that running with an older Service Worker causes remote asset requests to fail until the updated Service Worker becomes active.
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.
For now, we are adding both headers in an attempt to be backward compatible with clients running stale service workers.
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.
Oh, both headers is a lovely idea ❤️
@brandonpayton let's find a way to not introduce the coupling between PHP and WordPress. The decoupled design paid off dozens of times and once we start coupling, it will quickly become impossible to untangle. |
@adamziel thanks for the review! I reviewed all your comments and think we're on the same page.
I think we can decouple by using a single callback to determine a fallback for all file-not-found conditions. I have a messy version working locally. The gist is:
This allows PHPRequestHandler to be decoupled from WordPress. With this approach, the remote worker-thread maintains the WordPress-specific parts, including remote static file responses and handling file-not-found conditions with WP index.php. Planning to clean this up and push tomorrow morning unless you disagree with the direction. |
That sounds great @brandonpayton, thank you! |
e04fdb8
to
ed7bf01
Compare
@adamziel PHPRequestHandler is decoupled from WordPress again, and this is ready for another review. I'm really happy with how the file-not-found callback approach allows us to keep special file-not-found handling logic within the packages that need it. |
type: 'response', | ||
response: new PHPResponse( | ||
404, | ||
{ 'x-file-type': ['static'] }, |
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.
X-file-type static doesnt mean much anymore in this context when it also works for .php paths, it would be nice to tell the service worker „please fetch from the server” using a different object shape
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’m just pointing at the string used)
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.
Yeah, it's not great. Unfortunately, I haven't figured out how to adjust this and not break for clients still running with the older Service Worker:
From this comment:
That's a good opportunity to rename this to more clearly communicate the intention. Perhaps 'x-file-source': 'remote-server', 'x-backfill-from': 'remote-host', something similar?
@adamziel Is it OK for us to leave this magic header as-is for now? I made the update but quickly discovered that running with an older Service Worker causes remote asset requests to fail until the updated Service Worker becomes active.
One thing we could do for now is send the new preferred header while continuing to send the old, like:
{
'x-backfill-from': [ 'remote-host' ],
// Include this header for remote assets via out-of-date service worker
'x-file-type': [ 'static' ],
}
I'm planning to go this route for now.
fa6d45f
to
0489507
Compare
@adamziel This is ready for another review. |
Almost there @brandonpayton! Let's also rebase to make sure this works well with the latest trunk and the last few PRs @bgrgicak merged |
This should be ready to merge, but there are some odd test failures in CI that I have not been able to reproduce locally. Planning to take another look tomorrow. |
This PR: - Updates PHPRequestHandler to support custom file-not-found responses - Updates worker-thread to configure PHPRequestHandler to handle file-not-found conditions properly for WordPress - Updates worker-thread to flag remote WP assets for retrieval by the Service Worker Prior to this PR, we could not easily tell whether we should request a missing static asset from the web or delegate a request for a missing file to WordPress. Related to #1365 where we need better information to judge whether to handle a request for a missing static file as PHP. - CI tests - Test manually with `npm run dev` and observe that Playground loads normally with no unexpected errors in the console
c24f038
to
5010b1d
Compare
This reverts commit 4b09a5f.
…ution into multiple processes
…est execution into multiple processes" This reverts commit 55d9830.
When these are included, GH auto-cancels the CI unit test workflow.
The CI unit test errors appear to go away when we reduce the number of tests for PHPRequestHandler. To confirm this isn't a real PHPRequestHandler issue, we can switch between
If both of those pass, I plan to reduce the number of docRoot/absoluteURL permutations for the time being. |
If we have to revert the request routing changes, it may leave some users with a Service Worker from those routing changes, so we want to make sure the service worker still supports loading remote assets in response to the x-file-type header.
This reverts commit a0e853d.
Both combinations passed with no issues. For now, we can reduce the number of docRoot/absoluteURL permutations until we can figure out why the CI unit test workflow is being auto-canceled. (guess: hitting some kind of memory limit) |
Motivation for the change, related issues
This PR updates PHPRequestHandler to route HTTP requests more like a regular web server.
Prior to this PR, we could not easily tell whether we should request a missing static asset from the web or delegate a request for a missing file to WordPress.
Related to #1365 and #1187
Implementation details
This PR:
Testing Instructions (or ideally a Blueprint)
npm run dev
and observe that Playground loads normally with no unexpected errors in the console