<p dir="auto">Right now, <a href="https://golang.org/src/net/http/pprof/pprof.go?s=6283:6333#L197" rel="nofollow">https://golang.org/src/net/http/pprof/pprof.go?s=6283:6333#L197</a> has a</p>
<div class="highlight highlight-source-go notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="func Index(w http.ResponseWriter, r *http.Request)"><pre class="notranslate"><span class="pl-k">func</span> <span class="pl-en">Index</span>(<span class="pl-s1">w</span> http.<span class="pl-smi">ResponseWriter</span>, <span class="pl-s1">r</span> <span class="pl-c1">*</span>http.<span class="pl-smi">Request</span>)</pre></div>
<p dir="auto">which only works if the path on which it is serving is exactly <code class="notranslate">/debug/pprof/</code>.</p>
<p dir="auto">This is weakly documented, and also a little inconvenient, as handling other paths may be desirable. In particular, its behaviour if you <em>do</em> assume that it can be hosted on other paths is that every profile you try to get returns the index page.</p>
<p dir="auto">It would be nice to fix this so that it supports arbitrary path prefixes. The ways that occur to me to implement this are:</p>
<ol dir="auto">
<li>
<p dir="auto">Rather than extracting the expected path suffix up-front and looking it up in the profiles map, iterating over the available profiles and checking whether they are a suffix of the requested path (possibly the longest suffix). This is a little less efficient (O(1) profile lookup becomes O(|available profiles|), but the number of profiles should be small and this handler shouldn't be hit too often or on many critical paths.</p>
</li>
<li>
<p dir="auto">Introduce a function which takes the path prefix and returns a handler suitable for that prefix. It preserves the current performance characteristics, but leaves the old slightly-broken method there for backwards compatibility, at the cost of requiring duplication of the prefix specification (both in the Handle call and in the Index-creator-func), and generally feeling slightly ugly.</p>
</li>
</ol>
<p dir="auto">I'm inclined towards implementing the first; does anyone have any strong opinions?</p>
<pre class="notranslate">My CL that expanded the maximum runtime memory to 128 GB appears to have broken race
detection on the Windows build machine. I will disable the test for now so that the
build machine stays useful.</pre>