
Ask HN: Why does 'View Source' issue a new HTTP request? - koolba
I&#x27;ve noticed that both Firefox and Chrome issue a new HTTP request when you view the source for a web page that you&#x27;ve already loaded. It&#x27;s particularly annoying when the page itself is slow to load or if it won&#x27;t load at all.<p>Why is that? Wouldn&#x27;t they have the existing source for the originally received page cached already? Is it based on Cache-Control headers?<p>This has been on my mind for a while (usually comes up when looking at what&#x27;s behind slow web apps) and came up again with Piwik on the front page[1]. Their website was semi-down (HN hug of death) but eventually loaded. I wanted to see what their GA equivalent tracking code looks like but the page failed to load as rather than showing the cached copy, it tried to fetch a new one.<p>[1]: https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13210195
======
spookylukey
It's a bug:
[https://bugzilla.mozilla.org/show_bug.cgi?id=307089](https://bugzilla.mozilla.org/show_bug.cgi?id=307089)

Or, it's a memory saving feature. To implement "View source from cache"
requires keeping around the raw page HTML, which you might not otherwise need
after parsing - except you probably will for all the developer tools to work,
so this probably should just be considered bug.

~~~
chx
How much memory is saved here?
[http://www.httparchive.org/interesting.php?a=All&l=Dec%202%2...](http://www.httparchive.org/interesting.php?a=All&l=Dec%202%202016)
52 _kilobytes_ ? Really?

~~~
morley
The browser would have to save the source text for EVERY tab it opens,
regardless of whether you view source or not. That seems more onerous than
making a separate request for the source code every once in a while.

~~~
amelius
Yes, but if you have more than enough memory, then that's no problem.

So, the browser should load the HTML page into a part of memory that can be
discarded by the OS if the OS needs more memory. Actually I think it is
strange that no such memory API exists in Unix.

EDIT: Anyway, storing it in the browser's file cache would also do the trick,
I suppose :)

~~~
Insanity
Isn't that one of the issues nowadays, that people have the attitude "we have
enough memory" and thus don't tend to care about optimizing for memory usage
anymore.

Your suggested solution, about discarding when memory is needed, solves this
problem. But it solves a problem that would be created by needlessly storing a
lot more data than needed. So it's a solution to a problem that was not a
problem to begin with.

But I know, if it's a few kb, it will not make a huge difference.

~~~
user5994461
> "we have enough memory"

Your phone is in disagreement.

~~~
dagw
My phone has a quite insane 3 GB of RAM.

~~~
mbertschler
My phone also has the insane 3GB of RAM, but last week Chrome killed Spotify
and vice versa (music stopped playing) as soon as I switched apps. Sadly 3GB
is not enough for Android and todays apps.

------
oneeyedpigeon
I wish View Source were more flexible. I would like:

* Raw: a view of the actual body as sent in the response. Although I'm not aware of the current situation, at least some browsers used to subtly alter what was sent, even for View Source (possibly related to validity corrections). I want a _guarantee_ that what I'm viewing is what the server sent.

* View source as it is today (with a good common understanding of what that means), but a bit more powerful. Give me a cursor so I can copy from the keyboard, for crying out loud! Maybe even let me edit the source so I can work with static pages more easily.

* Something in-between View Source and DOM inspector. E.g. the original source, guaranteed to be untouched by javascript, but cleaned-up for easier reading (given that the source returned by many websites nowadays is practically unreadable (take a look at this page, for example). Reformatting (where possible), maybe automatic expansion of any base href, consistent ordering of attributes, highlighting of errors, etc.

~~~
eptcyka
You can always use curl. Chrome allows you to copy paste a full curl command
(with all the arguments and cookies) to issue an identical http request.

~~~
dagw
Identical Http requests don't necessarily return identical data.

------
czep
Once the DOM is ready, the browser has no need to keep the original source in
memory or cache. For how many page views does the user want to view source?
One in a thousand? You're asking the browser to waste space storing something
that it will only rarely be asked to display.

~~~
phaser
it could be garbage collected when user closes the tab.

------
oneeyedpigeon
They (well, Chrome at least) even do that for a POST, which is highly
questionable.

------
jmkni
I usually have Fiddler running constantly in the background.

If a page is slow to load and I want to see the HTML, I would find the actual
HTTP request in fiddler and grab the HTML that way.

Alternatively, the element inspector doesn't re-issue the request, but it will
show the _compiled_ HTML, so after DOM augmentation etc

~~~
TheRealWatson
Is there anything comparable to Fiddler for macOS? I heard you can run it in
VM but that's just too much brute force for me.

~~~
fastball
Fiddler is available for MacOS.

~~~
TheRealWatson
Interesting. I had no idea they had a beta version for macOS. I've gotta try
it.

------
nikbackm
Maybe the HTML source is discarded after the browser has built the DOM object
tree?

------
mwill
I think it may just be because in both cases it opens in a new tab with the
view-source modifier, it treats it like you just opened a copy of the page in
a new tab?

I believe if you open the inspector instead it does not issue a new request.

~~~
koolba
> I think it may just be because in both cases it opens in a new tab with the
> view-source modifier, it treats it like you just opened a copy of the page
> in a new tab?

Interesting. I never payed attention to the resource prefix. Are those
standardized at all? Both Firefox and Chrome use the same "view-source:"
prefix.

> I believe if you open the inspector instead it does not issue a new request.

The inspector shows the current DOM, not the original loaded HTML, which could
be different. It's probably "good enough" as in most cases the original HTML
would be the simpler one (say a single div for a single page app) and the live
DOM would show what look like right now.

~~~
rohansingh
It's not the prefix/scheme that's important, it's the fact that it's a new
tab.

------
junke
I seem to recall that it wasn't always the case.

~~~
INTPenis
True and I was shocked that the referenced mozilla bug[1] is from 2006. Time
really flies because it feels like yesterday I could view source without re-
loading it.

[1]:
[https://bugzilla.mozilla.org/show_bug.cgi?id=307089](https://bugzilla.mozilla.org/show_bug.cgi?id=307089)

~~~
samet
Sweet memories:

[http://imgur.com/a/p02cQ](http://imgur.com/a/p02cQ)

------
karmakaze
I once wondered this, but didn't think much of it. Now seeing the question, it
seems quite clear. The DOM+CSS+javascript is pretty much like a computer
running a (self-modifying) program. If it didn't do a fresh fetch, then what
you'd be seeing is the contents of 'memory' after the program has been running
some time. This is useful in itself, so we have Inspect. If you want to see
the initial state, the program before execution begins, then you want to View
its source(s).

------
jutaz
I'm not exactly sure why browsers do that, but I suspect that's due to
caching.

However, I would suggest that you use "Inspect element" and open up dev tools
- this way you will see DOM exactly as it is rendered.

~~~
aplummer
Often the dom has been changed, and you want to know what the server actually
sent

~~~
jbm
You can still do that with the inspect menu; if you look at the network
history in Chrome, you can see the headers sent, the headers received and the
body sent / received.

~~~
koolba
> You can still do that with the inspect menu; if you look at the network
> history in Chrome, you can see the headers sent, the headers received and
> the body sent / received.

That only works if you have it open before the page loaded. It doesn't save
information about network requests that occurred before the inspector was
opened.

~~~
noir_lord
It would be handy if it did though since I continually forget to open
inspector before the request.

I'd love a "I'm a developer, store all the things!" setting

------
anonymfus
In Opera up to 12.x it does not.

------
bbarn
I suppose in today's web ecosystem, the initial HTML state of the page is
useless in almost all cases after the DOM loads. Rarely will you care about
the pre-javascript page, and if you do, you're probably debugging a web site,
and the extra load shouldn't matter.

Where it could get interesting though, is if the content changes before you
view the source. In that case, you're out of luck I guess.

------
seanwilson
I wouldn't think view-source is a highly used feature that benefits from
optimising much and your scenario sounds rare. If a "view-source:..." URL is
entered into the browser directly you would need to write code to grab the
page from scratch anyway so doing this always makes the logic simpler.

------
msie
Yeah, that always annoyed me. So far, i dont see any answer in this page.
Really curious, tho.

------
f0code
The html returned from the already performed HTTP action has been consumed,
rendering the view in the browser. If you want to view the raw HTML instead,
'View Source' requests another copy of it, but does not render it.

------
WallWextra
Same with save page, etc.

------
Bugseverywhere
Bug? Wow

