Zero: Added nosniff header.

2016-01-22T03:04:37Z

Added nosniff header.

← Older revision		Revision as of 03:04, 22 January 2016
Line 101:		Line 101:
	**The web browser does not know how to handle it because it does not recognize imaage		**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		*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		**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====		====Response Headers====

LeeCroft at 15:36, 21 January 2016

2016-01-21T15:36:28Z

← Older revision		Revision as of 15:36, 21 January 2016
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

			====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)

Soma at 21:21, 19 January 2016

2016-01-19T21:21:08Z

← Older revision		Revision as of 21:21, 19 January 2016
Line 1:		Line 1:
			==Video==

			The video for the lecture given on January 19, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec04-19Jan2016.mp4 is now available].

	==Notes==		==Notes==

Zero: Added in-class notes.

2016-01-19T20:52:37Z

Added in-class notes.

New page

==Notes==

===In-class Notes===

<pre>
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

</pre>

WebFund 2016W Lecture 4 - Revision history

Zero: Added nosniff header.

LeeCroft at 15:36, 21 January 2016

Soma at 21:21, 19 January 2016

Zero: Added in-class notes.