Sorry, the link is https://github.com/Manishearth/rust-http/compare/chris-morgan:master...Manishearth:discombobulate
-Manish Goregaokar On Sat, Jul 19, 2014 at 1:40 AM, Manish Goregaokar <manishsm...@gmail.com> wrote: > 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
