-
-
Notifications
You must be signed in to change notification settings - Fork 709
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
WIP: Extend WebSession to support range requests. #2887
base: master
Are you sure you want to change the base?
Conversation
@zenhack How do you feel about this issue and WIP? It was specifically mentioned as a pain point recently. |
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.
A few comments, but this looks basically reasonable.
@@ -181,6 +188,7 @@ interface WebSession @0xa50711a14d35a8ce extends(Grain.UiSession) { | |||
mimeType @0 :Text; |
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.
A bit of a tangent, but: would it actually break anything to delete PutContent per the comment? the layout is exactly the same so it should be wire compatible. The type IDs are different, but it's hard for me to imagine that anything uses that.
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.
It'd be wire-compatible, but not source-compatible. Some apps could have their builds broken. Maybe we don't care that much...
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 doubt very many apps actually use this directly, and for the ones that do it's a trivial fix. But probably doesn't make sense to change it as part of this patch.
position @2 :UInt64; | ||
} | ||
|
||
fullSize :union { |
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.
As far as I can tell, this is only valid in responses. Maybe we should remove it, since we only currently use the Range struct in requests?
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.
Huh. It's been a long time since I wrote this, but I wonder if I had intended to include a Range
under Response.content
but forgot... otherwise I'm not sure how the Content-Range
header is supposed to be constructed for the response.
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.
See the comment you wrote below -- looks like the idea was to just insist that the app returns the range that was actually asked for, so the supervisor only needs to check the status code.
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.
But how is the overall size communicated? I guess the final Content-Range
header would always end up ending in /*
?
BTW, what makes you say that fullSize
is not valid for requests? It doesn't appear in a GET request (Range
header), but a PUT that is uploading a range (Content-Range
header) could include it, right? (However, I'm not sure if it's actually worth supporting range PUTs...)
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.
Yes, I was only thinking about GET requests. I guess I don't feel that strongly about this.
|
||
# This seems to fit better here than in the 3xx range | ||
# TODO(apibump): Only the three status codes above should actually be used. The status codes |
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.
s/three/four/
This is just the protocol change for now. Someone additionally needs to update
proxy.js
andsandstorm-http-bridge.c++
and perhapsbridge-proxy.c++
.