CSC/ECE 517 Fall 2015/oss/M1502/AAAASS: Difference between revisions
No edit summary |
|||
(One intermediate revision by the same user not shown) | |||
Line 21: | Line 21: | ||
=='''Code Changes'''== | =='''Code Changes'''== | ||
==='''Adding pipeline Id'''=== | |||
Pipeline id was added in http_loader.rs file for request and response messages. | Pipeline id was added in http_loader.rs file for request and response messages. | ||
Line 77: | Line 79: | ||
} | } | ||
</pre> | </pre> | ||
Changes were also made to the load_whole_resource function inside lib.rs for adding pipeline id | |||
<pre> | |||
pub fn load_whole_resource(resource_task: &ResourceTask, url: Url, pipeline_id: Option<PipelineId>) | |||
-> Result<(Metadata, Vec<u8>), String> { | |||
let (start_chan, start_port) = ipc::channel().unwrap(); | |||
resource_task.send(ControlMsg::Load(LoadData::new(url, pipeline_id), | |||
LoadConsumer::Channel(start_chan))).unwrap(); | |||
let response = start_port.recv().unwrap(); | |||
let mut buf = vec!(); | |||
loop { | |||
match response.progress_port.recv().unwrap() { | |||
ProgressMsg::Payload(data) => buf.push_all(&data), | |||
ProgressMsg::Done(Ok(())) => return Ok((response.metadata, buf)), | |||
ProgressMsg::Done(Err(e)) => return Err(e) | |||
} | |||
} | |||
} | |||
</pre> | |||
==='''Refactoring '''=== | |||
== '''Test '''== | == '''Test '''== |
Latest revision as of 03:58, 7 November 2015
M1502: Improve HTTP monitoring devtool support
Firefox supports remote developer tools - ie. communicating with an arbitrary server that implements a protocol for exposing information about web content. Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by exposing further information about HTTP requests and responses that web content initiates. <ref>https://github.com/servo/servo/wiki/Expand-HTTP-request-response-monitoring</ref>.
Github Location
https://github.com/akumar21NCSU/servo
Build Process
git clone https://github.com/servo/servo cd servo ./mach build --dev ./mach run tests/html/about-mozilla.html
Forked Branch
A branch was forked from https://github.com/servo/servo and placed at the following location: https://github.com/akumar21NCSU/servo
Development
The primary goal of the development effort is to support the presence of a pipeline id. The goal is to pass values to send_request_to_devtools derived from the actual request. The request containing the new pipeline id. The development command is: ./mach build --dev
Code Changes
Adding pipeline Id
Pipeline id was added in http_loader.rs file for request and response messages.
fn send_request_to_devtools(devtools_chan: Option<Sender<DevtoolsControlMsg>>, request_id: String, url: Url, method: Method, headers: Headers, body: Option<Vec<u8>>, pipeline_id: PipelineId) { if let Some(ref chan) = devtools_chan { let request = DevtoolsHttpRequest { url: url, method: method, headers: headers, body: body, pipeline_id: pipeline_id }; let net_event = NetworkEvent::HttpRequest(request); let msg = ChromeToDevtoolsControlMsg::NetworkEvent(request_id, net_event); chan.send(DevtoolsControlMsg::FromChrome(msg)).unwrap(); } }
fn send_response_to_devtools(devtools_chan: Option<Sender<DevtoolsControlMsg>>, request_id: String, headers: Option<Headers>, status: Option<RawStatus>, pipeline_id: PipelineId) { if let Some(ref chan) = devtools_chan { let response = DevtoolsHttpResponse { headers: headers, status: status, body: None, pipeline_id: pipeline_id }; let net_event_response = NetworkEvent::HttpResponse(response); let msg = ChromeToDevtoolsControlMsg::NetworkEvent(request_id, net_event_response); chan.send(DevtoolsControlMsg::FromChrome(msg)).unwrap(); } }
This required us to change HttpRequest and HttpResponse structs in lib.rs file inside devtool_traits.
pub struct HttpRequest { pub url: Url, pub method: Method, pub headers: Headers, pub body: Option<Vec<u8>>, pub pipeline_id: PipelineId, }
pub struct HttpResponse { pub headers: Option<Headers>, pub status: Option<RawStatus>, pub body: Option<Vec<u8>>, pub pipeline_id: PipelineId, }
Changes were also made to the load_whole_resource function inside lib.rs for adding pipeline id
pub fn load_whole_resource(resource_task: &ResourceTask, url: Url, pipeline_id: Option<PipelineId>) -> Result<(Metadata, Vec<u8>), String> { let (start_chan, start_port) = ipc::channel().unwrap(); resource_task.send(ControlMsg::Load(LoadData::new(url, pipeline_id), LoadConsumer::Channel(start_chan))).unwrap(); let response = start_port.recv().unwrap(); let mut buf = vec!(); loop { match response.progress_port.recv().unwrap() { ProgressMsg::Payload(data) => buf.push_all(&data), ProgressMsg::Done(Ok(())) => return Ok((response.metadata, buf)), ProgressMsg::Done(Err(e)) => return Err(e) } } }
Refactoring
Test
A unit test is added to test the new functionality of the pipeline id. The testing is run by performing the following command in the command line: ./mach test-wpt
Implementation
Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by exposing further information about HTTP requests and responses that web content initiates. <ref>https://github.com/servo/servo/wiki/Expand-HTTP-request-response-monitoring</ref>
Project Benefits & Challenges
Benefits:
1. Helps add additional debug to the HTTP monitoring in Servo
2. Provides developers capability of monitoring the data traffic
3. Mozilla messages are clearly analyzed using Servo
Challenges:
Rust code development presents a challenge as the build environment takes time to build. Adding additional filters to the Servo causes failures initially as development tends to be a hit or miss. Communicating with both the TA and the Mozilla team members is critical. It is generally expected that new changes should not introduce new crashes in the testsuite however this was not the case. The team did encounter crashes when unit tests were carried out.
Design Pattern
The requirements did not require us to implement any design pattern.
External Links
Also see:
References
<references/>