Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd file backend support for Blob and related #11221
Conversation
highfive
commented
May 17, 2016
|
Heads up! This PR modifies the following files:
|
highfive
commented
May 17, 2016
|
@Manishearth I refined the design a bit and I think we can push the progress of this thread in parallel with #11189 |
| typeString: String, | ||
| isClosed_: Cell<bool>, | ||
| } | ||
|
|
||
| #[derive(Clone, JSTraceable)] | ||
| pub struct BlobImpl { | ||
| slice: DOMRefCell<Option<DataSlice>>, |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
izgzhen
May 17, 2016
Author
Contributor
I am thinking about the possibility of caching here. If it is file-backed, we can put the cached content inside the other DataSlice field.
This comment has been minimized.
This comment has been minimized.
Manishearth
May 17, 2016
Member
I'd rather have an enum here and within the FileId variant have an option for caching. As it stands slice = Some can mean cached or an in-memory slice, a clear boundary would be nicer and more Rusty.
| } | ||
|
|
||
| pub fn get_bytes(&self) -> Vec<u8> { | ||
| match *self.slice.borrow() { |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
izgzhen
May 18, 2016
Author
Contributor
Currently I don't put any read operations in blob.rs, which means that the user needs to check if it is cached and then cache if necessary. Or, if the file is not cached, a empty slice or stuff with similar semantics will be returned.
This comment has been minimized.
This comment has been minimized.
Manishearth
May 18, 2016
Member
I feel like blob.rs should handle get_bytes either way. Of course it shouldn't be the one doing the reading, but it should talk to the resource task and fetch the reads and handle caching.
This comment has been minimized.
This comment has been minimized.
izgzhen
May 18, 2016
•
Author
Contributor
It am not sure if it is possible to fetch a reference to the window within Blob itself, which means that I can access script_thread stuff.
This comment has been minimized.
This comment has been minimized.
highfive
commented
May 18, 2016
|
New code was committed to pull request. |
|
@Manishearth In order to get port to filemanger thread inside blob (by |
|
Exposing it won't hurt anything; the storage APIs aren't accessible from workers, so there hasn't been any need to make the storage thread available. |
|
Any particular reason for workers not being able to use storage? If there's a security reason we should not even give workers an unused storage chan (sandboxing). |
|
Seems like it used to be for security reasons but now it's just for "threading issues". |
|
I didn't see any |
|
Oh, sure, the spec doesn't let you, the question is: If a sandboxed worker was compromised with an RCE vulnerability and got access to storage data, is that an escalation of access? Assuming that we have checks in place in the resource/storage thread that ensure that no process gets data from a different origin (we don't, but we should eventually), I don't think this is an issue. Also, I don't see us putting workers in separate processes, so if a worker thread is compromised the script thread would be compromised too anyway. |
| let file_manager: IpcSender<FileManagerThreadMsg> = unimplemented!(); | ||
| let (chan, recv) = ipc::channel().unwrap(); | ||
| let _ = file_manager.send(FileManagerThreadMsg::ReadFile(chan, id)); | ||
| let result = recv.recv().unwrap(); |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
izgzhen
May 20, 2016
Author
Contributor
I think read_file can be made Option<DataSlice> and we can throw a script-level exception or something at the dom API where it is used (like Slice)
This comment has been minimized.
This comment has been minimized.
| @@ -313,7 +313,8 @@ impl HTMLFormElement { | |||
| content_disposition, | |||
| content_type)); | |||
|
|
|||
| result.push_str(from_utf8(&f.upcast::<Blob>().get_data().get_bytes()).unwrap()); | |||
| let slice = f.upcast::<Blob>().get_slice(); | |||
| result.push_str(from_utf8(&slice.get_bytes()).unwrap()); | |||
This comment has been minimized.
This comment has been minimized.
Manishearth
May 20, 2016
•
Member
Not necessarily utf8 here? The charset can change.
We should handle errors too.
|
Almost done! |
highfive
commented
May 20, 2016
|
New code was committed to pull request. |
|
|
| @@ -308,12 +308,17 @@ impl HTMLFormElement { | |||
| DispositionParam::Filename(Charset::Ext(String::from(charset.clone())), | |||
| None, | |||
| f.name().clone().into())); | |||
| /// XXX: unwrap | |||
This comment has been minimized.
This comment has been minimized.
Manishearth
May 23, 2016
Member
replace it with an expect
though in this case unwrap_or(text/plain) might be better?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
|
|
|
Add file backend support for Blob and related - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy --faster` does not report any errors - [x] These changes fix #10851, related to #11131 - [x] These changes do not require tests because the implementation is partial and can't work alone 1. Add new backend to `Blob` and a `BlobImpl` struct to abstract multiple backends 2. Rewrite most interfaces of `Blob` to accommodate the change 3. Change the `read` behaviour of `FileReader`, considering the case when blob is file-backed and not cached The design is still immature, welcome comments! - [x] I used `DOMRefCell` to cache the bytes in `BlobImpl`, is it sound? - [x] The interfaces (like `BlobImpl::get_bytes`) handle requests in a default-to-empty way when the inner `DataSlice` is not cached. It might be possible to handle this condition better. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11221) <!-- Reviewable:end -->
|
|
highfive
commented
Jun 1, 2016
|
|
@bors-servo try |
|
@bors-servo retry |
|
|
Add file backend support for Blob and related - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy --faster` does not report any errors - [x] These changes fix #10851, related to #11131 - [x] These changes do not require tests because the implementation is partial and can't work alone 1. Add new backend to `Blob` and a `BlobImpl` struct to abstract multiple backends 2. Rewrite most interfaces of `Blob` to accommodate the change 3. Change the `read` behaviour of `FileReader`, considering the case when blob is file-backed and not cached The design is still immature, welcome comments! - [x] I used `DOMRefCell` to cache the bytes in `BlobImpl`, is it sound? - [x] The interfaces (like `BlobImpl::get_bytes`) handle requests in a default-to-empty way when the inner `DataSlice` is not cached. It might be possible to handle this condition better. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11221) <!-- Reviewable:end -->
|
|
|
|
Add file backend support for Blob and related - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy --faster` does not report any errors - [x] These changes fix #10851, related to #11131 - [x] These changes do not require tests because the implementation is partial and can't work alone 1. Add new backend to `Blob` and a `BlobImpl` struct to abstract multiple backends 2. Rewrite most interfaces of `Blob` to accommodate the change 3. Change the `read` behaviour of `FileReader`, considering the case when blob is file-backed and not cached The design is still immature, welcome comments! - [x] I used `DOMRefCell` to cache the bytes in `BlobImpl`, is it sound? - [x] The interfaces (like `BlobImpl::get_bytes`) handle requests in a default-to-empty way when the inner `DataSlice` is not cached. It might be possible to handle this condition better. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11221) <!-- Reviewable:end -->
|
|
|
@bors retry try-
|
|
@bors-servo retry try- |
Add file backend support for Blob and related - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy --faster` does not report any errors - [x] These changes fix #10851, related to #11131 - [x] These changes do not require tests because the implementation is partial and can't work alone 1. Add new backend to `Blob` and a `BlobImpl` struct to abstract multiple backends 2. Rewrite most interfaces of `Blob` to accommodate the change 3. Change the `read` behaviour of `FileReader`, considering the case when blob is file-backed and not cached The design is still immature, welcome comments! - [x] I used `DOMRefCell` to cache the bytes in `BlobImpl`, is it sound? - [x] The interfaces (like `BlobImpl::get_bytes`) handle requests in a default-to-empty way when the inner `DataSlice` is not cached. It might be possible to handle this condition better. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/11221) <!-- Reviewable:end -->
|
|
|
|
izgzhen commentedMay 17, 2016
•
edited
./mach build -ddoes not report any errors./mach test-tidy --fasterdoes not report any errorsMajor changes
Bloband aBlobImplstruct to abstract multiple backendsBlobto accommodate the changereadbehaviour ofFileReader, considering the case when blob is file-backed and not cachedThe design is still immature, welcome comments!
Problems to resolve
DOMRefCellto cache the bytes inBlobImpl, is it sound?BlobImpl::get_bytes) handle requests in a default-to-empty way when the innerDataSliceis not cached. It might be possible to handle this condition better.This change is