Re: [dev-servo] HTTP referer disabled by default
> However, do see Brian Smith's recent proposal on this topic: > https://briansmith.org/referrer-01.html This looks extremely reasonable. Is there any reason not to adopt this in Servo and see if it works? jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] HTTP referer disabled by default
I don't see any, however since Servo isn't being dogfooded yet, there's not much data we can gather on this (yet). Still, it would be interesting to hide a bunch of "useful" web platform features behind some flags, add some specific reporting/logging, and see how many of them are really needed (and if they break important things) whilst dogfooding. An even more drastic proposal could be to switch to just serving " http://fake.path"; for anything cross-origi (à la C:/fakepath/ for file upload paths) -- The existence of a URL, despite being wrong, ought to help avoid break the web, at the same time providing much better security guarantees that (eventually) webapp devs don't have to worry about. Though this is for the standards people to decide. -Manish Goregaokar On Wed, Feb 4, 2015 at 7:05 PM, Jack Moffitt wrote: > > However, do see Brian Smith's recent proposal on this topic: > > https://briansmith.org/referrer-01.html > > This looks extremely reasonable. Is there any reason not to adopt this > in Servo and see if it works? > > jack. > ___ > 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
Re: [dev-servo] HTTP referer disabled by default
On 04/02/15 14:57, Manish Goregaokar wrote: > I don't see any, however since Servo isn't being dogfooded yet, there's not > much data we can gather on this (yet). > > Still, it would be interesting to hide a bunch of "useful" web platform > features behind some flags, add some specific reporting/logging, and see > how many of them are really needed (and if they break important things) > whilst dogfooding. For general features you get much better data from adding telemetry to an existing widely used engine like Gecko or Blink. Therefore the value of doing this in Servo seems rather low. If there are features that we think are rarely used and that we would prefer not to implement, running experiments on Gecko seems like the easiest way forward (although I think the details of the way Gecko's telemetry works makes it harder to collect all the same data that is available through Blink infrastructure) In this specific case the kind of question that needs to be answered is more difficult since it's not of the form "is client side feature X used at all". Unfortunately I guess that Servo is still a way away from being able to help with that kind of question because there are so many possible reasons for a site not working that it's hard to pin it on one specific thing. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Servo memory usage
Last year I claimed that Servo had a number of huge stacks, as reported by /proc//smaps. It turns out that these measurements are inaccurate -- if a non-stack mapping gets placed next to a stack mapping, the kernel merges them and the merged segment is marked as a stack. I've confirmed this happens by looking at the output of strace. It's also something I should have known since it came up in Firefox in bug 827691. Nick On Fri, Jul 11, 2014 at 12:04 PM, Brian Anderson wrote: > > On 07/10/2014 11:11 PM, Nicholas Nethercote wrote: >> >> On Thu, Jul 10, 2014 at 10:34 PM, Patrick Walton >> wrote: >>> >>> Historically, Rust's large stacks were due to the fact that at the time >>> stack growth was removed, rustc had worse codegen than it did today, >>> resulting in frames with very large activation records. Coupled with the >>> fact that rustc itself uses recursion heavily (probably too heavily), the >>> easiest thing to do was to give tasks large stacks by default. Perhaps >>> this >>> decision should be revisited, as I think that it may well be the case >>> that >>> rustc is going to be the exception, not the rule. >>> >>> You can tune the size of stack growth when spawning a Rust task. Servo >>> could >>> definitely use a stack size audit; I bet a ton of MBs can be shaved off >>> with >>> some tuning. >> >> "Large default stack size" doesn't seem to explain it. >> >> I'd guess that the default is 2 MiB, because there are quite a few >> entries in smaps like this: >> >> 7f54091fe000-7f54093fe000 rw-p 00:00 0 >>[stack:28143] >> Size: 2048 kB >> Rss: 12 kB >> Pss: 12 kB >> >> 2 MiB has been allocated, but only a tiny amount has been touched and >> is thus in RSS. >> >> Here are the two biggest stacks: >> >> 7f540a70-7f540b80 rw-p 00:00 0 >>[stack:28139] >> Size: 17408 kB >> Rss:7944 kB >> Pss:7944 kB >> >> 7f540960-7f540a40 rw-p 00:00 0 >>[stack:28141] >> Size: 14336 kB >> Rss:8192 kB >> Pss:8192 kB >> >> For both, |Rss| is big and |Size| (equivalent to vsize) is even bigger. >> > > Rust does have 2MB stacks by default. These giant numbers are surprising. > > > ___ > 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
