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

WIP: Extend WebSession to support range requests. #2887

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kentonv
Copy link
Member

@kentonv kentonv commented Mar 12, 2017

This is just the protocol change for now. Someone additionally needs to update proxy.js and sandstorm-http-bridge.c++ and perhaps bridge-proxy.c++.

@ocdtrekkie ocdtrekkie added the app-platform App/Sandstorm integration features label Jan 15, 2020
@ocdtrekkie
Copy link
Collaborator

@zenhack How do you feel about this issue and WIP? It was specifically mentioned as a pain point recently.

Copy link
Collaborator

@zenhack zenhack left a 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;
Copy link
Collaborator

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.

Copy link
Member Author

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...

Copy link
Collaborator

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 {
Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Collaborator

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.

Copy link
Member Author

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...)

Copy link
Collaborator

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

Choose a reason for hiding this comment

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

s/three/four/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app-platform App/Sandstorm integration features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants