The one time I have actually been asked this question it sure felt like the interviewer was expecting a certain explanation rather than trying to start a conversation. Hard to tell, since that was the only technical question I got asked in that phone interview and they rejected me after that.
If somebody is going to ask those questions in an interview, at the bare minimum this person must know deeply about the subject, so they can recognize a correct answer and judge their quality. Instead, from how people talk about this (I've personally stopped interviewing for a while) it looks like everybody asking those has no idea what a correct answer looks like, and just expects candidates to follow a script.
There are two things to note. First, it is incredibly unlikely that your interviewer knows deeply about both the HTTP protocol and databases implementation. Thus, anybody asking both is already full of bullshit. Second, it may be valuable to get a hold of the interviewer script and study it. People full of bullshit are not normally very creative, so the scripted answer should be easy to find at Google.
If I have to study things unrelated to my job for some shibboleth interview, that's time I could have spent on my actual skills instead. Besides, any interview that does not demonstrate my ability to write a unit test and encapsulate data and functionality means I know what horrors I'm likely to encounter when I get to the code.
What happens between you typing a URL into your browser address bar? isn't a question that requires a canned response to be parroted back – it's a starting point for a conversation about your knowledge of the web technology stack. It's not at all like there is a 'correct' answer, but demonstrating that you have a vague idea of how parts work, can identify gaps in your own knowledge, and make reasonable choices about how you might fill them.
Maybe what are the things you should consider if you were writing your own database server? is somewhat less directly applicable to most jobs, but I'd argue much the same sort of thing applies – it's a kicking-off point for a conversation about systems that you should have at least rudimentary knowledge about.
I'm curious as to what you would prefer in a technical interview - more directly relevant questions about the specific systems you would be working on?