Persistent sessions student project

Implement HTTP authorization UI and persistent sessions

Background information: Users routinely use web pages that support the notion of sessions. Logging into and using a web-based email reader relies on the web browser transmitting certain session data with every request to allow the web server to associate them with each other. Servo supports this today, but it doesn't support persisting this data when the web browser is closed and reopened. The intent of this project is to create the infrastructure to support this.

Initial steps:

• compile Servo and ensure that it runs on tests/html/about-mozilla.html
• email the mozilla.dev.servo mailing list introducing your group and your progress
• add a new command line flag --profile-dir [path] that stores an optional directory path in the Opts struct in opts.rs, creating the directory if it does not exist.
• create Rust FFI bindings for the tinyfiledialogs library to allow calling the C methods from Servo
• in resource_thread.rs, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an Arc<Rwlock<>> value, to enable sharing it between threads)
• in modify_request_headers in http_loader.rs, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.

Subsequent steps:

• make an authorization UI appear when a 401 HTTP response is received (StatusCode::Unauthorized) - in load in http_loader.rs, right before trying to process an HTTP redirection, use the new tinyfiledialogs library to make two prompts appear (username and password), then restart the request with the new authorization value present applied. If an authorization value was present and the response is successful, add the credentials to the authorization cache. See an example of how authorization behaves in other browsers.
• if the profile directory command-line option is present when the ResourceThread is instructed to exit, serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.
• perform the same serialization on shutdown for local_data in storage_thread.rs, which represents the LocalStorage API.
• check for the presence of the profile directory command-line option in the ResourceThread constructor and look for files that will contain serialized versions of the previous steps. If they exist, populate the appropriate fields with deserialized versions of the file contents.