WebFund 2016W Lecture 4: Difference between revisions
No edit summary |
Added nosniff header. |
||
(One intermediate revision by one other user not shown) | |||
Line 37: | Line 37: | ||
</pre> | </pre> | ||
===Student Notes=== | |||
====Announcements==== | |||
*Assignment 1 due tomorrow (now pushed back to Thursday before class) | |||
*Basics for tutorial 2 and assignment 2 are up! | |||
====Web Servers==== | |||
*What does a web server do? | |||
**Listens on port 80 (usually HTTP), 443 (usually HTTPS) or some other port. | |||
***If the web server is listening on a non-standard port, you must specify the port in the URL (using something like “localhost:8080”) | |||
**Input: HTTP requests | |||
**Output: HTTP responses with requested documents | |||
***HTTP responses always have a response code | |||
****200: OK, used for successful request | |||
****404: Not Found | |||
**In other words it services requests | |||
*Need root privileges to listen on ports <~1024 | |||
**Do not do development as root if you can, it is risky! | |||
*Popular Web Servers: Apache, NginX | |||
====Tiny Web Server==== | |||
*Written in JavaScript(Node) | |||
*Can only serve files! (most modern servers can do more) | |||
*Understands limited file types | |||
*Similar to web servers from 1995 | |||
*To try to understand what the code is doing, we can start by looking at the bottom of the file | |||
=====http.createServer()===== | |||
*Apart from the loading of some modules and the definitions of some objects and functions, the first real code to run in this script is the <code>createServer()</code> method | |||
*We are calling a method of the <code>http</code> object (loaded from a module) in order to create an object which will act as the server (which we then store in the <code>server</code> variable) | |||
*This method takes a single argument, <code>request_handler</code> | |||
**<code>request_handler</code> is a function which is intended to handler incoming requests | |||
**By providing this function as the argument, we are telling the server to call the function every time a request comes in | |||
=====server.listen()===== | |||
*Here we are calling the <code>listen()</code> method of the <code>server</code> object that was just created | |||
*This tells the server to start listening for incoming requests | |||
*The first two arguments are telling the server where to listen (on port 8080 of localhost) | |||
**This information came from the <code>options</code> object which was defined at the top of the file | |||
*The third argument is a callback function | |||
**This will run once the server has started listening | |||
**It simply prints a message in the console to indicate that the server is ready | |||
=====request_handler()===== | |||
*This function gets called every time a request comes in (because we provided it as an argument to the <code>http.createServer()</code> method) | |||
*There are two arguments | |||
**<code>request</code> is an object which represents the request that was received | |||
**<code>response</code> is an object which represents the response that will be sent | |||
*At a high level, this function checks for the existence of a requested file and responds with either the file or an error code | |||
*There are many nested callback functions here | |||
**Although this makes the code more difficult to read, why is this preferable to doing things synchronously? | |||
***This ensures that the <code>request_handler()</code> function will return very quickly | |||
***All the bulk of the work is done asynchronously | |||
***This allows the server to be available to handle another request again very quickly | |||
***This is important in order to keep the server responsive for numerous requests | |||
====MIME Types==== | |||
*MIME types are used to specify the type of data being sent via HTTP | |||
*In Tiny Web Server, there is an object <code>MIME_TYPES</code> defined near the top of the file which contains the types of files that the server recognizes | |||
*The <code>MIME_TYPES</code> object is used in the <code>get_mime()</code> function to determine the type of a requested file | |||
*Similarly, the <code>MIME_TYPES</code> object is used to set the Content-Type header of the HTTP response that is sent by the server | |||
*We can break ‘image/jpg’ by changing it to ‘imaage/jpg’ | |||
**The web browser does not know how to handle it because it does not recognize imaage | |||
*Web browsers can deal with broken content type for some types of files | |||
**For example, putting a jpg as png in <code>MIME_TYPES</code>, will not break the content and Firefox is smart enough to render it correctly as jpg | |||
**To prevent the browser from attempting to detect what format the content is, the <tt>X-Content-Type-Options: nosniff</tt> header can be added. | |||
====Response Headers==== | |||
*Some headers of the HTTP response are set in the <code>respond()</code> function | |||
**This is done using the <code>response.writeHead()</code> method | |||
**We could add more headers here if we want to | |||
*Some other headers are set for us by the code in the <code>http</code> module | |||
*We can see these headers from within the dev tools of the web browser after a response has been received | |||
*There are not many headers used here because Tiny Web Server is not very complex | |||
====Frameworks and Modern Servers==== | |||
How have things improved since 1995? | |||
*We use code to generate responses to requests | |||
**We often use frameworks to do much of the work for us | |||
Why use frameworks? | |||
*Because we don’t want to build up HTML from scratch | |||
*Abstracted away logic | |||
*We also want routing (dispatcher): have someone else decide which function to call in response to requests | |||
====Debugging==== | |||
*You can use the node debugger by typing <code>node debug script.js</code> in the terminal | |||
*This will stop the program on the first line of code that is run | |||
*You can continue execution of the code by typing <code>c</code> | |||
*You can learn about other useful commands by typing <code>help</code> | |||
*In particular, you can type <code>repl</code> to enter a read-evaluate-print loop from which you can inspect or modify objects or other data | |||
*You can also write <code>debugger;</code> in the script to create a break point where the debugger will pause the execution of the program | |||
*There is also a debugger available in the web browser | |||
**This is for client side code and will not work for any server-side code | |||
====HTML==== | |||
*You can use the inspect in the web browser dev tools to see the the tree-structure HTML which makes up a web page | |||
*<code><div></code> tags are used for sections in HTML | |||
*<code><a></code> tags are used for links (review on CodeAcademy) |
Latest revision as of 03:04, 22 January 2016
Video
The video for the lecture given on January 19, 2016 is now available.
Notes
In-class Notes
Lecture 4 --------- Web servers What does a web server do? Listens on port 80, 443, or other port INPUT: HTTP requests OUTPUT: HTTP responses & requested documents tinywebserver.js - written in JavaScript (Node) - can only serve files - understands only a few file types So tinywebserver is how web servers worked in 1995 What changed since then is now web servers run code to generate responses Why use frameworks? - because we don't want to build up HTML from scratch - and, we want logic that is abstracted away - and, we want routing - have someone else decide which function to call in response to requests But for this week, bare bones Debugging
Student Notes
Announcements
- Assignment 1 due tomorrow (now pushed back to Thursday before class)
- Basics for tutorial 2 and assignment 2 are up!
Web Servers
- What does a web server do?
- Listens on port 80 (usually HTTP), 443 (usually HTTPS) or some other port.
- If the web server is listening on a non-standard port, you must specify the port in the URL (using something like “localhost:8080”)
- Input: HTTP requests
- Output: HTTP responses with requested documents
- HTTP responses always have a response code
- 200: OK, used for successful request
- 404: Not Found
- HTTP responses always have a response code
- In other words it services requests
- Listens on port 80 (usually HTTP), 443 (usually HTTPS) or some other port.
- Need root privileges to listen on ports <~1024
- Do not do development as root if you can, it is risky!
- Popular Web Servers: Apache, NginX
Tiny Web Server
- Written in JavaScript(Node)
- Can only serve files! (most modern servers can do more)
- Understands limited file types
- Similar to web servers from 1995
- To try to understand what the code is doing, we can start by looking at the bottom of the file
http.createServer()
- Apart from the loading of some modules and the definitions of some objects and functions, the first real code to run in this script is the
createServer()
method - We are calling a method of the
http
object (loaded from a module) in order to create an object which will act as the server (which we then store in theserver
variable) - This method takes a single argument,
request_handler
request_handler
is a function which is intended to handler incoming requests- By providing this function as the argument, we are telling the server to call the function every time a request comes in
server.listen()
- Here we are calling the
listen()
method of theserver
object that was just created - This tells the server to start listening for incoming requests
- The first two arguments are telling the server where to listen (on port 8080 of localhost)
- This information came from the
options
object which was defined at the top of the file
- This information came from the
- The third argument is a callback function
- This will run once the server has started listening
- It simply prints a message in the console to indicate that the server is ready
request_handler()
- This function gets called every time a request comes in (because we provided it as an argument to the
http.createServer()
method) - There are two arguments
request
is an object which represents the request that was receivedresponse
is an object which represents the response that will be sent
- At a high level, this function checks for the existence of a requested file and responds with either the file or an error code
- There are many nested callback functions here
- Although this makes the code more difficult to read, why is this preferable to doing things synchronously?
- This ensures that the
request_handler()
function will return very quickly - All the bulk of the work is done asynchronously
- This allows the server to be available to handle another request again very quickly
- This is important in order to keep the server responsive for numerous requests
- This ensures that the
- Although this makes the code more difficult to read, why is this preferable to doing things synchronously?
MIME Types
- MIME types are used to specify the type of data being sent via HTTP
- In Tiny Web Server, there is an object
MIME_TYPES
defined near the top of the file which contains the types of files that the server recognizes - The
MIME_TYPES
object is used in theget_mime()
function to determine the type of a requested file - Similarly, the
MIME_TYPES
object is used to set the Content-Type header of the HTTP response that is sent by the server - We can break ‘image/jpg’ by changing it to ‘imaage/jpg’
- The web browser does not know how to handle it because it does not recognize imaage
- Web browsers can deal with broken content type for some types of files
- For example, putting a jpg as png in
MIME_TYPES
, will not break the content and Firefox is smart enough to render it correctly as jpg - To prevent the browser from attempting to detect what format the content is, the X-Content-Type-Options: nosniff header can be added.
- For example, putting a jpg as png in
Response Headers
- Some headers of the HTTP response are set in the
respond()
function- This is done using the
response.writeHead()
method - We could add more headers here if we want to
- This is done using the
- Some other headers are set for us by the code in the
http
module - We can see these headers from within the dev tools of the web browser after a response has been received
- There are not many headers used here because Tiny Web Server is not very complex
Frameworks and Modern Servers
How have things improved since 1995?
- We use code to generate responses to requests
- We often use frameworks to do much of the work for us
Why use frameworks?
- Because we don’t want to build up HTML from scratch
- Abstracted away logic
- We also want routing (dispatcher): have someone else decide which function to call in response to requests
Debugging
- You can use the node debugger by typing
node debug script.js
in the terminal - This will stop the program on the first line of code that is run
- You can continue execution of the code by typing
c
- You can learn about other useful commands by typing
help
- In particular, you can type
repl
to enter a read-evaluate-print loop from which you can inspect or modify objects or other data - You can also write
debugger;
in the script to create a break point where the debugger will pause the execution of the program - There is also a debugger available in the web browser
- This is for client side code and will not work for any server-side code
HTML
- You can use the inspect in the web browser dev tools to see the the tree-structure HTML which makes up a web page
<div>
tags are used for sections in HTML<a>
tags are used for links (review on CodeAcademy)