What's in a HTTP request
rdig opened this issue · comments
I recently got this question in a interview, and I think it's quite fitting that we mention it here as well:
What are the parts that make up a HTTP request ?
What do you guys think? Will you accept a PR for it?
Well those are the headers, which are just part of the request, no ?
Warning - subjective opinions ahead.
Domain knowledge over a specific topic isn't what you should be interviewing for. If the candidate doesn't know HTTP2 protocols (which wouldn't surprise me at this time of writing), it's something they can learn if they absolutely need to.
What you should be interviewing for is the ability to solve problems and be adaptable. In almost all cases, candidates that show strong signs of these two traits will be the most successful, as they are the ones that can learn a new language on the drop of a dime or pick up a new technology overnight when your projects call for it.
I've even considered developing an interview question that uses a fake programming language just to see their reasoning for a solution to a problem (or even using a stack based language). Yes, it's hard - but I feel like the field has been setting the bar too low to begin with. I want to see how they react to something new, and see if they can reason about approaching something that isn't regurgitated factual information.
If you can google it in a reasonable amount of time, you shouldn't be interviewing for it.
There is obviously the need to ensure they know basic design principles as well as coding knowledge, but there's a reason why I always combat "signals" people get when they interview for a specific technology (i.e. jQuery or React specifically).
Not every candidate is going to have the same background, and by isolating specific knowledge (or the lack thereof) you're going to be missing out on a lot of potentially kickass employees.
Just my thoughts.
As someone else mentioned, it's partially covered under the question which asks about certain headers, but I'd argue that it's also sort of covered in the following question: "Do your best to describe the process from the time you type in a website's URL to it finishing loading on your screen."
To me this is a great question that leaves a lot of room for discussion and the interviewer can dig a little deeper if the answer given isn't sufficient. At a minimum I would expect candidates to know that headers are sent with the request, but I wouldn't expect them to rattle off a list of headers because that's not really that important.
If they mention a few then perhaps it's a bonus, but FE developers rarely look at headers. I inspect network traffic on a daily basis on the enterprise app I work on, but I'm far more focused on looking at response data/time and almost never look at the headers.
Anyway, if it were me then I'd rephrase the question to the one I listed above then list out the following steps.
- HTTP GET request is made to the server to request a resource for the given Request-URI which includes a few common request headers.
- Server responds with a Status Code of 200 indicating that the request was successful along with the document in the response body and a few common headers.
- The document received in the response body is parsed by the browser (HTML parser) and DOM tree construction begins. Note that as script tags are encountered (assuming they are synchronous) parsing halts while the script is loaded and executed as this is a blocking operation.
- As the DOM tree is being constructed, the CSS parser begins constructing the CSSOM tree as the parser encounters stylesheets, embedded styles, or inline styles.
- At the same time, the DOM and CSSOM are combined to create the Render Tree (i.e. visual representation of the DOM). The Render Tree consists of visual elements (renderers, aka rectangles) in the order in which they will be displayed. This is where style computation happens (selector rule matching) as each element has its visual properties calculated.
- Layout (aka Reflow) then occurs on each element to calculate the exact position and size (box model).
- Finally, the Render Tree is passed to the paint process to render the pixels on the screen allowing the user to interact with the document.
This question reminds me of an interview question I had where the interviewer asked, "Can you tell me how a browser works?" This was so uncomfortable and difficult to get through as the question is so broad it was hard for me to get to the one point that the interviewer wanted to hear.
I'd agree that someone who has in-depth recall memory about how all of this works is probably not a front-end developer. I'd put this in the category of "let me google that ..."
That being said, I think that there is value to have a question in regards to HTTP/2 in the Performance section.
Tidying!