Okay, so the past few days I've been playing around with rust-http. The main issue is that the headers code stores pre-parsed headers (as strings or other types), doesn't handle badly encoded headers too well, and makes mistakes while encoding (leading to icky workarounds like this <https://github.com/mozilla/servo/pull/2765>). I figured out three ways of getting around this:
- Completely rewrite the headers module to a simpler one. I tried this at the beginning of the week, wasn't able to get somewhere with it the first try. I might try again later. - Fix all encoding issues in rust-http by simply ensuring that encoding/decoding is done correctly at every point. I don't feel this is doable, since rust-http doesn't store the original bytes and encoding/decoding isn't always a one-one mapping in case of malformed stuff. - Rewrite the Header class to contain bytes, and rewrite HeaderCollection to be a simple collection, with minimal changes to the exposed API. I've tried out the third one and this <https://github.com/Manishearth/rust-http/compare/chris-morgan:master...master> is what I have so far. It still has some encoding issues but I don't see how to solve them without major changes (eg the first option, which will take time to get right). It's in a good enough state to use for starting rust-fetch, however, and can be swapped in with our current rust-http with minor changes (only where the headers are being accessed as HeaderCollection fields). I will have another go at a complete rewrite of headers later, since that has the capacity to get rid of all encoding issues (so does Teepee if it gets finished). If I ever get enough time, I might try my hand at a simplified Rust http library -- I feel that this is something the community does need at some point; but that's probably not going to happen yet. I'll probably get started on rust-fetch Sunday. Semester starts Monday, progress might be a bit slow (fortunately cors.rs contains a lot of the stuff I need for rust-fetch) -Manish Goregaokar On Mon, Jul 7, 2014 at 7:39 PM, Patrick Walton <pcwal...@mozilla.com> wrote: > On 7/7/14 6:17 AM, Manish Goregaokar wrote: > >> Teepee is the replacement for rust-http but it's progressing rather slowly >> right now. It's also "over-engineered" (as Simon puts it), but it seems to >> fix most of rust-http's problems. I guess we'll eventually be switching >> over to Teepee. >> > > That's not a given as far as I'm concerned. Whenever Teepee materializes, > we'll have to evaluate it on its own merits relative to Servo's needs. > > One option is to simply fork rust-http and replace most of the complicated >> strongly-typed objects with simpler ones, and separate out the parsing >> code. I probably can do this, but I'm not sure. This might even be useful >> as a permanent replacement for rust-http (that we maintain) since it's >> simpler and we don't really use the bits I propose to replace except in >> XHR >> (which would be simplified by the change). >> >> Couple of questions: >> >> - Do we want a Fetch crate? If so, what's the best way to handle its >> >> http library? (One option is to simply wait for Teepee) >> > > I personally think it's likely a worthwhile endeavor to start on an HTTP > client crate. As I understand things, browsers haven't had a lot of luck > reusing external HTTP libraries, because their needs are so specific (perf > and bug-for-bug compatibility with every weird Web server out there). > > There's also the issue of SSL support. We need it sooner rather than > later, because we're starting to want to really do testing against top-100 > sites and a large number of them are SSL-only. > > This is not meant as a slight against Teepee; if we need to, we can merge > our work or switch over, as the case may be. > > Patrick > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo