SimonSapin: You around?

nox: hey

SimonSapin: Hello. Does it make sense that in layout_2013, DisplayInside has variants such as Block or Inline?

it’s… surprising

but I’m not familiar with this

SimonSapin: Seems like I'm almost done with the DOM traversal code.

nice

Ah no I still have quite a few pieces of code commented-out.

ping servo/servo #24153#issuecomment-529129022

SimonSapin: We have some lifetime issues around BoxSlot.

I'll think about how to fix them.

SimonSapin: We put the AtomicRefCell<LayoutBox> in an AtomicRefCell<StyleAndLayoutData> in layout_2020,

Task "Servo daily: Windows x64: Nightly build and upload. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/NRWJyiVQQs2J-CtOMQZUeQ

so we can never have a BoxSlot<'dom> from the AtomicRefMut<LayoutBox>,

not sure which way I'm going to fix that mmh…

Tempted to make BoxSlot be a wrapper of Option<Arc<AtomicRefCell<Option<LayoutBox>>>>.

.clone()

Task "Servo daily: Android Nightlies: Nightly build and upload. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/FjAGS87SRv-hR8qKxZ2BfQ

nox: let's not have nested refcells?

Then you can use RefCell::map

I'm not sure I can.

Maybe I misread something though.

SimonSapin: Yeah I'm dumb disregard me.

SimonSapin: So I think I can get an AtomicRefMut<'dom, Option<LayoutBox>> in the end.

It's lunch time though.

rust-lang/rust #64310 Oops.

jdm: I'm wondering if I should add a state machine for module scripts or not 🤔 currently, I can use the `GetWaitForAllPromise` function to do a `Promise.all` but we don't have `await` so that I must do something after getting the promise. (ex. saving a list of promises in document and check its status in each event loop tick?)

jdm: I can append native handlers to the promise created by `Promise.all` but I didn't figure out a place to `resolve` or `reject` it 😓

cybai: wouldn't you resolve/reject the promise in the FetchListener implementation for a particular request?

jdm: if the module doesn't have any descendants, the promise will be resolved

that is, the events that are being used in the Promise.all would be resolved/rejected by the fetch response handler code

and the promise returned by Promise.all would be automatically resolved/rejected by Promise.all's implementation

ohh!!!! 🤯 that sounds what Promise.all should behave!! 🤔

ahhh!! yeah, let me try it!

I'm not sure why I was stuck in resolving / rejecting a Promise.all 😱

thanks!

cybai: my one concern is when we call Promise.all - is there a point at which we know we have requested all the modules for a particular graph?

cybai: otherwise do we keep calling Promise.all each time there is a new module to request and ignore any previous promise?

jdm: I think yes, we save all fetched module in `module_map` in global scope. and I will traverse all descendant urls which are not fetched / fetching

aha

so if the module is fetching, it will just return the fetching promise.

I guess if the promise resolve handler checks the module map and does nothing if it's still incomplete, that should probably be fine

👀 didn't try this way before. let me see what will happen!

hmm, interesting... building with `regex` 1.3 with `std` feature costs `34m 41s` and building with current master costs `32m 16s` 🤔

on my macOS

I read that regex takes 34 minutes to build on your machine. regex itself.

That was scary.

jdm: I'm landing a thing that I hate today: code that is not called and with commented out parts, but that's so SimonSapin and I share the same code.

yeah, I feel that

First commit with my new email tho :p

nox: inb4 github doesn't accept it because weird TLD *hides*

eijebong: Nah it's already my account email.

Task "Servo daily: Android Nightlies: Nightly build and upload. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/J9vaq8f9R6-OcoV_twLXpQ

jdm: Plot twist: I broke layout 2013.

oops

jdm: See, I checked a normal build even though it's not on your damn checklist. :P

nox: oh, I mean building Servo 😂 but with different regex version

nox: pretty sure `mach build -d` is in the checklist ;)

nox: the one in the PR template?

SimonSapin: Yeah.

jdm: Damn.

eijebong: same :)

eijebong: same :D

all y'all are doing checklists wrong

Nice, glad to know I'm not alone in that boar

boat*

SimonSapin: I delete it without actually checking anything and then jdm puts it on our 1:1 agenda.

I always only run `./mach fmt` locally 😂

I want to make a joke but I can't English.

who checks the checklists?

You can ask someone for a service or a favour,

🙋‍♂️

but what's the expression for when you are the one doing the work?

Oh, it's just the verb do.

I don't check the checklist as a favour to jdm, to keep him on edge and he doesn't find management boring.

ha

nox: Yeah but CI does it for us :(

eijebong: Still costs CI cycles for no reason though.

I am a moron and just get deeply offended by HTML or Markdown boilerplate in my merge commits.

nox: Yeah. It should not even try to build if tidy doesn't pass :p

jdm: do we have a plan to move off python 2? python.org/doc/sunset-python-2

SimonSapin: I think we're waiting for mach on that ?

Last time I looked at it it was the case at least

does mach upstream have a plan?

SimonSapin: the plan largely relies on work being done in mozilla-central and wpt; there's a list of pieces in an issue as well

I see "A future version of pip will drop support for Python 2.7" in some logs

yep

and virtualenv likes to always install the latest pip

SimonSapin: is that something we can control?

I don’t know

ah, pip.pypa.io/en/latest/development/release-process/#python-2-support is more nuanced

it looks like it’s "support" as in "maintainers look at bug reports", not "it runs at all"

(in practice there are millions of lines of largely unmaintained Python 2 code in the world and various support contracts that will keep providing security fixes for at least 5 years, so it's not the emergency that people would like you to believe)

(not saying it's a bad idea to port ofc)

jgraham: r? servo/servo #24121

So layout_2013 builds,

but I have some style changes,

so CI may explode, we'll see.

+99/-98

nox: would you prefer landing only an import of victor/src/layout/fragments.rs?

that we could both work on top of

SimonSapin: Nah it should be ok.

jdm, SimonSapin: Btw I didn't realise at first, but I think it's trivial in layout 2020 to remove the init_style_and_layout_data stuff.

Which kills a huge amount of weird code where we have to comment with stuff such as "yeah this field is in DOM but it needs to be dropped by layout btw, be careful friends".

nox: what changes that makes this easier?

SimonSapin: We don't need a weird trait object to be stored in DOM objects.

jdm: 🤯 oh!!! I cannot believe I just pass `/html/semantics/scripting-1/the-script-element/module/single-evaluation-2.html` with removing `.resolve_native` of the promise all 🤯🤯🤯🤯🤯

nice!

My life atm consists of staring at wireshark captures of WPT runs.

TIL that the wpt http server responds "HTTP/1.1 200 OMG" rather than "OK".

ajeffrey: what are you looking for?

but I believe I didn't handle the fetched case well 😂 will try to see if there's a WPT test for this case (I mean, if the module is fetched earlier)

Task "Servo daily: macOS x64: WPT update. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/c_dOq-lGTzqQycGTk3cjQg

jdm: trying to work out why we're now getting charset decoding failures when prefetching.

The document doesn't get prefetched, so this is super odd.

ajeffrey: Huh? I think some test might but in general we shouldn't c.f. searchfox.org/mozilla-central/sourc…s/wptserve/wptserve/constants.py#36

ajeffrey: searchfox.org/mozilla-central/sourc…orm/tests/xhr/resources/status.py#3

presumably github.com/web-platform-tests/wpt/b…4020a1b2/xhr/resources/status.py#L3 and github.com/web-platform-tests/wpt/b…b2/fetch/api/resources/status.py#L3

SimonSapin: Sorry got distracted.

Running tidy and fmt one last time and then pushing.

jgraham: the URL being requested is [Full request URI: web-platform.test:8000/xhr/resource…application%2Fxml%3Bcharset%3Dutf-8]

ajeffrey: Right, that specific file intentionally overrides the normal status text

jgraham: I don't thiiiink that's related to the test failure I'm seeing, which is about decoding failure, it was just odd to see.

jdm: running wireshark did make me realize that the prefetching is a bit too simplistic, in that it always prefetches, even if the parser isn't blocked yet,

e.g. we get two GETs of testharness.js because the prefetch and the regular fetch happen simultaneously.

ajeffrey: so in theory our http cache layer should be preventing two gets from occurring

"Can't automatically merge."

Of course.

if that's not happening we should figure out why

jdm: that's what I thought, but wireshark says otherwise :/

it's possibly because the second GET happens before the cache-control headers have arrived back from the first one.

thank goodness wpt runs on http not https :)

SimonSapin: What did you do in fragment?

SimonSapin: Completely forgot I had a local "Kill fragments" commit lol.

eh

And also I had a lot of missing dependency updates locally,

so now I'm rebuilding the world again.

nox: so you removed all the "second pass" layout code? (going from boxes to fragments)

Classic "I'm making a PR in 5 minutes" becoming 5 hours.

SimonSapin: Yeah.

ok

so it sounds like I should do my own import of victor/src/layout/fragments.rs, and we’ll figure out later how to connect it with your stuff

SimonSapin: Making a PR today at the very least.

SimonSapin: If you try to import fragment you'll need to make some changes that I already did.

(Using the right stylo types etc.)

nox: so you made changes to fargments.rs, then deleted it?

SimonSapin: The opposite.

I deleted fragment.rs, and then imported Victor.

ah, layout_2013’s fragment.rs

Yeah sorry.

I'll call it a day after I make the PR I think,

standups: Made more progress porting the DOM traversal code from Victor to the machinery in Servo, encountered a small blocker in the form of lifetime issues, but that should not be too complicated to fix.

standups: Did some code speleology for a mergefunc bug in rustc/LLVM/macOS' ld/whatever other tool is broken in that toolchain.

SimonSapin: Also,

I had to silence a bunch of warnings,

because everything is dead code obviously.

right

I feel so dirty doing that, but yeah we need to.

Ah, the decoding is getting messed up way down in html5ever...

Lies, h5e is perfect.

somehow the text got decoded from windows-1252 into UTF-8, then reinterpreted as windows-1252, then into UTF-8 again.

fascinating

nox: I have done horrible things to the tokenizer, so it's unhappy with me.

standups: fixing lint issues blocking WPT sync. pushing on UWP build failures on CI.

SimonSapin: You almost hated me.

?

SimonSapin: Was going to create the PR with "Cc @SimonSapin" in its description.

2 days after we all got spammed because of GH mentions in PR descriptions. :D

haha

indeed

I liked how there were three separate repositories flooding me

jdm: Cool templates and greetings! :P irccloud.mozilla.com/file/EQC8mg0O/…2019-09-09%20a%CC%80%2018.13.49.png

ahhhh... I think I figured out the issue... SimonSapin help me you're my only hope

at github.com/servo/servo/blob/master/…/script/dom/servoparser/mod.rs#L441 we push a string into the buffer,

but it converts it to bytes as UTF-8, not as whatever the network decoder is expecting?

Holy hell I made so few PRs this year against servo/servo.

ajeffrey: that method takes a String parameter, so it’s Unicode not bytes

ajeffrey: By the time you are calling this method you already converted the input.

SimonSapin: but the network decoder might be expecting a different encoding?

ajeffrey: The network decoder calls that after it decoded.

IIRC.

what is the network decoder?

github.com/servo/servo/blob/174bcc4…pt/dom/servoparser/mod.rs#L490-L496 push_string_input_chunk has only one caller, and the passed strings are not from the network at all.

What you want is the stuff line 434.

looks like push_string_input_chunk (as opposed to push_bytes_input_chunk) is used when bytes or character encodings are not involved at all

Ok,

PR filed,

LLVM bug investigated,

calling it a day.

nox SimonSapin: well parse_html_document calls parse_string_chunk at github.com/servo/servo/blob/5bcb1b5…/script/dom/servoparser/mod.rs#L158

ajeffrey:Yes.

ajeffrey: Did you look at the callers of parse_html_document?

ajeffrey: You already have a string when you call that.

So I still don't get what encoding you mean to talk about.

github.com/servo/servo/blob/da559d4…/script/dom/xmlhttprequest.rs#L1402 XHR input, already decoded

oh jinx

github.com/servo/servo/blob/f1dd31f…ponents/script/dom/domparser.rs#L56 ParseFromString, obviously a string, already UTF-8 by definition.

github.com/servo/servo/blob/068997c…nents/script/script_thread.rs#L3304 ScriptThread::load, empty string.

but the network decoder for the XHR might not be UTF8?

ajeffrey: Which is why it passes a decoded string?

I don't understand what your issue is here.

well the test that's failing due to me mucking around with servoparser is...

xhr/responsedocument-decoding.htm

ajeffrey: You do agree that the things you link will never get anything but UTF-8 though, right?

ajeffrey: Which test case is failing?

Cause there are already expected failures there.

oh yes, the string is in UTF8, it's the network decoder that might be non-UTF8.

And one of them is text/html: github.com/servo/servo/blob/master/…esponsedocument-decoding.htm.ini#L6

ajeffrey: Did you check that your failure isn't the same as the expected one, but maybe with different garbage in its name?

XMLHttpRequest: response document decoding (text/html %3C!doctype%20html%3E%3Cmeta%20charset%3Dwindows-1252%3E%3Cx%3E%e6%a9%9f%3C%2Fx%3E)

vs

XMLHttpRequest: response document decoding (text/html;charset=windows-1252 %3C!doctype%20html%3E%3Cmeta%20charset%3Dwindows-1252%3E%3Cx%3E%e6%a9%9f%3C%2Fx%3E)

yes, those are different tests aren't they?

Yeah.

so there's a test that used to pass and is now failing due to me mucking around,

So my understanding is that you broke windows-1252 decoding, which was already working when the encoding is stated as a HTTP header.

and I can't work out why it used to pass :(

ajeffrey: Because we decode the input before we pass it to the function you mentioned first. :)

Hi, I am new to servo and am looking to contribute as part of a course i'm taking. I'm looking for some help with what is feasible. I'm curious about implementing IndexedDB or atleast some of it. I saw some estimate of it taking > 12 months. I don't see how the 12 months are justified. Do you think I could get some of it working until mid-december?

ajeffrey: See this: github.com/servo/servo/blob/da559d4…/script/dom/xmlhttprequest.rs#L1402

but the network decoder is windows-1252 isn't it?

ajeffrey: And this: github.com/servo/servo/blob/da559d4…t/dom/xmlhttprequest.rs#L1506-L1513

ajeffrey: Yes? Line 1402 we decode from windows-1252 to UTF-8, getting a string.

yes, and then push it back to the network decoder,

ajeffrey: No we don't.

ajeffrey: I think I understnad your issue.

ajeffrey: Did you misread network_input into network_decoder?

Cause those are different things.

push_string_input_chunk pushes to network_input, not ever touching the network decoder.

push_bytes_input_chunk goes through the network decoder. push_string_input_chunk doesn't, as SimonSapin said earlier.

nox: aaaaah!

OK, I'd messed that up.

ajeffrey: Imma going to pat me in the back for noticing a remote misreading.

nox: OK, let me try that and see if it fixes the issue.

I may add a comment to remind future!me what's going on!

rasviitanen: some of it? almost certainly yes.

nox++

@jdm tha'ts what I thought, just makking sure i'm nopt diving into too deep water

yay!

pcwalton: components/layout_thread currently keeps a long-lived DisplayList around inside LayoutThreadData, why is that useful?

is it sometimes needed again when it hasn’t changed?

I even wrote a comment to remind future confused devs (e.g. me) what's going on here... servo/servo #24148/commits/76e913970510fa1b523a60eacef8b568e3afb8d1

OK, now to work out why getting the same resource twice concurrently doesn't get cached.

standups: Debugging network decoding issues (thanks nox!)

Manishearth: alex turner pointed out that it might be possible to get a bare minimum extension for hololens webxr input based on the current openxr support

jdm: yes

but not hit testing

Manishearth: he mentioned a "select" action that is recognized by the implementation, I think. is hit testing still the long pole for adding any interactivity to webxr?

jdm: long pole from which POV?

idk about the openxr pov

hit testing is under active development on the spec side

there's an explainer with enough info that we could impl something experimental

but ideally you want device support

Manishearth: is there some way that hand pose information at the time of a selection action from openxr would be able to be used by the JS code to decide if somethign was hit?

jdm: yeah if JS code wants to do the work sure

and the APIs for getting the browser to do the work exist, experimentally (and in flux, but we could implement them)

yeah, that's something we could probably work with the babylon folks on, for example

but getting the browser to actually do the work would be annoying and we should let the device do it

aha

yeah

a tricky thing is figuring out exactly what the input profile is

OK, I think I can see what's going on with simultanous GETs not being cached, it's a locking issue.

like, you have two fingers, which are presumably both some form of primary input

ajeffrey: are we doing multiple short locks when we shouldn't?

but on their own they have no "selection" action

When we check to see if there's a cache entry for a request, we do it with a read-lock at github.com/servo/servo/blob/master/…components/net/http_loader.rs#L1011

the pinchy thingy is a selection action only for far away, which may need to be treated as a different input (?)

webxr does support transient inputs

like, fingers can be transient inputs

makes sense

and then if there's no cache entry, we go do the fetch, and add store the cache entry with a subsequent write-lock at github.com/servo/servo/blob/master/…components/net/http_loader.rs#L1120

so if two GETs arrive in quick succession, they'll both be cache misses, and so they'll both be fetched.

jdm: i was hoping to be able to experiment with hit testing but we can't till openxr has it

unless we do a native hl2 backend

(which ... we could, but it does seem like a lot of work)

ajeffrey: You're welcome.

ajeffrey: Oh btw,

ajeffrey: I *loved* that you were the one who added the damn bag characters to some TeX font, it made the rounds on Twitter last week.

I really dig seeing your name in the most unexpected places (unexpected to me).

nox: odd what things I ended up doing 25-or-so years ago that resurface :)

ajeffrey: Really wonder what it will be for me.

Hopefully no one will ever tweet about the stupid RSS reader written in C++ full of memory leaks that I added to an eMule mode 15 years ago.

mod*

nox: the other bit of font work from around then that made it into unicode is the reference design for blackboard bold.

it's odd seeing people using it for twitter handles etc.

Ah ah ah ah aha ah ah ah ah.

the design that's used these days is much nicer,

looks like it was done by an actual font designer.

TIL failIfMajorPerformanceCaveat

jdm: it's difficult to see how to make a concurrent implementation of fetch.spec.whatwg.org#http-network-or-cache-fetch which doesn't suffer from raciness on simultaneous fetches

since step 19.1 reads from the cache,

ajeffrey: what if we were to leave a placeholder entry when first reading if there is no cache entry?

sorry 5.19.1

then it gets killed if the eventual response can't be cached

and the store doesn't happen until 7.5.1.

jdm: is that spec compliant?

ajeffrey: if any subsequent readers waiting on that entry then make their own request, I don't see why not

it's possible this should be addressed at the spec level, though

jdm: my read of the spec is that checking the cache and updating the cache are two separate operations,

there's no atomic check-and-set :/

also for our implementation this is annoying because we lose the benefit of a read-write lock on the cache.

ajeffrey: we could make a side table that means "an uncached request is in progress, please wait on this condvar before checking the cache", perhaps?

jdm: for this particular case there's a fix (that is probably worth implementing anyway) which is to only prefetch content after the first <script> tag.

jdm: yeah, we could put another locking mechanism in place, but I'm a bit worried about introducing deadlocks in weird race conditions :(

indeed

standups: finally read through absolutely giant discussion about premultiplied alpha

Deadlocks are high maintenance, but I think your hair is long enough that you can go for it.

Manishearth++

right now my brain is in reverse matrix mode

nox: I force-pushed to your PR’s branch to add an intermediate commit with unmodified files from victor

Manishearth: Column or row order?

i don't see chairs, tables, the sky anymore

SimonSapin: Ok!

nox: you are trying to make me go bald? :)

all i see are rgba values

so I could have a diff in the next commit

nox: wrong matrix

ajeffrey: BE BOLD GO BALD

nox: make it so.

SimonSapin: It was only trivial changes!!1!

SimonSapin: Joke aside, sorry didn't even cross my mind that it would be a good thing to do.

nox: I was gonna ask you either do that or write a quick high level summary of changes, but since you said you’re done for today it was easy enough to do

SimonSapin: The changes were mostly "make it use style's types".

nox: does stylo not already have stuff for what’s in ComputedValuesExt ?

SimonSapin: Nope in a way that my brain was willing to comprehend.

like converting 'width' and 'height' to inline-size and block-size

SimonSapin: At the very least, the Sides types don't exist.

And the writing mode is a bitflags that I nope'd out of.

ah never mind, it’s likely using github.com/servo/servo/blob/master/…omponents/style/logical_geometry.rs

SimonSapin: Yeah and it doesn't look as good as what you did in Servo.

Err, Victor.

we can unify later (or not)

Yay! Only GETting the test harness once. irccloud.mozilla.com/file/I5OsK4Hp/…%20from%202019-09-09%2013-28-03.png

standups: Working on tests for surfman.

SimonSapin: at some point we should brainstorm what the ideal platform font interface would look like for CSS

I'm very willing to change font-kit

And yay, still doing concurrent HTTP GETs for three.js examples irccloud.mozilla.com/file/TxUz3osG/…%20from%202019-09-09%2013-31-58.png

jdm: for running servo in the emulator i have to ... do some things first, right?

just install the openxr thingy?

Manishearth: install the openxr package, yeah

do you know an easy way to do that?

Manishearth: and that needs to happen every time the emulator restarts

whAT

:/

Manishearth: either through windows update in the emulator or the store directly

ima try this on the device then

wait

Manishearth: there's a teams thread with a workaround we can use in the short term to package the openxr runtime with our builds

"payload file target\release\vcruntime140.dll doesn't exist

i thought i'd fixed this

oh the build failed this time

hm

(this was the x64 build)

standups: Diagnosing cache locking issues causing multiple requests for the same resource. (yay wireshark!)

jdm: OK, so servo/servo #24148/commits/58163a5c30d97757477078c50cd76cc37b63c65c is a workaround for the problem with simultaneous GETs both being cache misses,

I am inclined to file the underlying issue as a separate issue, file a spec issue about it, and move on. Sounds good to you?

pcwalton: sounds good. One unknown (to me) though is how much the css-font spec matches reality

agreed

jdm: OK, I will squash and r=you #24148 then

ajeffrey: there was a test failure in the last run

jdm: already fixed it

ah, o

k

dbaron: Do you know if Gecko deviates significantly from drafts.csswg.org/css-fonts/#font-matching-algorithm and how?

standups: slowly replacing gleam dependency in webgl/webvr with new crate

yay

+1

jdm: gist.github.com/Manishearth/ae0a63c25387ea00ce58f5ea30e96e5b

tips on debugging?

(got a mozilla-google webxr sync meeting in a bit but buffering this up for when you get a chance)

that looks exactly like what happened when I accidentally was loading non-arm64 DLLs in an arm64 build of servo

Manishearth: run dumpbin on all of the DLLs in the app package and look for suspicious headers?

like, just dump the headers, not all of the symbol data

jdm: ServoApp.exe?

or some other app package

Manishearth: actually start with the DLLs in your target/aarch64-pc-windows-msvc directory, I think

there should be no other DLLs involved

jdm: i have LIB_GST_OLD and GSTREAMER_1_0_ROOT_x86_64

SimonSapin: I'm not sure -- you'd have to ask jfkthame.

SimonSapin: I believe the main issue we have is that we don't currently handle the cluster-matching aspect of it

SimonSapin: aside from that, AFAIK we follow the algorithm pretty closely

I see, thanks

jfkthame: so you seem to be saying this is a gecko issue where it should improve, rather than a case of spec having what a WG would like but that doesn’t match what’s required for web-compat?

SimonSapin: yes, we have an open bug to improve this, and some work has been done a while back but we never quite got it finished :(

SimonSapin: still believe we should, though

standups: interview sync

boy there are a *lot* of uses of unwrap() in net::http_loader::http_network_or_cache_fetch servo/servo #24148#issuecomment-529678521

my guess is github.com/servo/servo/blob/f90dd12…/components/net/http_loader.rs#L886 is the one that's failing, since it's parsing a referrer URI.

believable

jdm: that bit of fetch code really doesn't like it if you feed it input it's not expecting, e.g. a referer that doesn't parse as a URI.

with good reason!

I mean it's proooobably right, but the spec is a bit looser

it only says "if the referer is a URL..."

ajeffrey: the spec deals in stuff like "pass a url or a global object to this algorithm"

standups: xr editor sync

OK, the problem seems to be something similar to hyperium/http #202

in that we have a URL that Servo's URL parser is happy about, but re-parsing it as a hyperium URL fails.

ajeffrey: wait does hyperium not use our parser?

i thought rust-url was ubiquitous

Manishearth: apparently not :/

no url dependency at github.com/hyperium/http/blob/master/Cargo.toml

wait it contains its own url parser, not even a separate crate? bummer

Yeah hyper doesn't use the url crate at all