-------------------------
Week 11 Notes for CST8165
-------------------------
-Ian! D. Allen - idallen@idallen.ca

Remember - knowing how to find out an answer is more important than
memorizing the answer.  Learn to fish!  RTFM!  (Read The Fine Manual)

Keep up on your readings (Course Outline: average 4 hours/week homework)

[************************************************************]
[************************************************************]
[*** Students should be taking their own notes in class   ***]
[*** and updating them with my published summaries.       ***]
[************************************************************]
[************************************************************]

http://teaching.idallen.com/cst8165/07w/notes/http_session.txt
http://teaching.idallen.com/cst8165/07w/notes/kurose/  (HTTP slides)

http://teaching.idallen.com/cst8165/07w/notes/lab07.txt
http://teaching.idallen.com/cst8165/07w/notes/autotest_http.sh.txt
http://teaching.idallen.com/cst8165/07w/notes/sample_http_test_out.txt
http://teaching.idallen.com/cst8165/07w/notes/sample_http_README.txt

Algonquin SMTP server
---------------------

Algonquin network restrictions prevent access to other SMTP servers from
on campus.  You must connect to the Algonquin SMTP server to send email.
In strict conformace with RFC 2821, the Algonquin SMTP server accepts
only CR+LF line ends - you have to type ^V^M^M (CTRL-V RETURN RETURN)
at the end of every line to make it work.

  $ nc -v outmail.algonquincollege.com smtp
  Connection to outmail.algonquincollege.com 25 port [tcp/smtp] succeeded!
  220 mail4.algonquincollege.com -- Server ESMTP (Sun Java System Messaging Server 6.2-7.02 (built Jun 13 2006))
  quit
  quit
  quit
  ...

  - connection hangs after the banner and it appears that it doesn't accept
    any further commands; because, the Sun server demands CR+LF line
    ends, not just LF line ends as given by "nc" (the Sun server is
    RFC-compliant; but, not very liberal in what it accepts!)
  - the fix is to enter ^V<CR><CR> (CTRL-V followed by pushing the
    RETURN key twice) at the end of each line:

  $ nc -v outmail.algonquincollege.com smtp
  Connection to outmail.algonquincollege.com 25 port [tcp/smtp] succeeded!
  220 mail4.algonquincollege.com -- Server ESMTP (Sun Java System Messaging Server 6.2-7.02 (built Jun 13 2006))
  quit^V^M
  221 2.3.0 Bye received. Goodbye.

Q: T/F, the Algonquin SMTP server violates the SMTP RFC by requiring CRLF
   on the end of each line.

===============================================================================

Overview of the Application Layer (slides)
------------------------------------------
- from Kurose/Ross:
  http://teaching.idallen.com/cst8165/07w/notes/kurose/  (HTTP slides)
  - includes HTTP slides showing Request and Response headers

===============================================================================

HTTP - Hyper Text Transfer Protocol
----
 First used in 1990
 http://tools.ietf.org/html/rfc2616 (HTTP 1.1 - June 1999 - 176 pages)

HTTP design issues by T.B-L
---------------------------
  http://www.w3.org/Protocols/DesignIssues.html

Q: Why did Tim Berners-Lee choose "Internet Protocol" instead of RPC for HTTP?

Q: Name one advantage and one disadvantage of coding HTTP using RPC.

Q: Does the HTTP server need to keep state information about the client?

Q:  Why is the stateless nature of HTTP a problem for such things as
    search systems?  How does Tim say the problems can be mitigated?

Many of Tim's original methods (e.g. "PORT") didn't make it into the
final HTTP specification.

HTTP protocol consists of Requests and Responses
------------------------------------------------
 http://tools.ietf.org/html/rfc2616
 Requests - Section 5
 Responses - Section 6

Unlike SMTP, the HTTP protocol is much more "symmetric" - the format
of what the client sends to the server looks a lot like what the server
sends back to the client.  You can both upload and download using HTTP.

An HTTP "Request" goes from client to server.  (From your web browser to
the remote server.)  A Request consists of a series of header lines of
the form "name: data" ending at an empty line (a line with just CRLF),
followed by an (often optional) body.  An HTTP "Response" comes back
from the server to you.  (From the server to your web browser.)  The
Response has the same header and body structure as the Request.

Q: What is an "HTTP Request"?  an "HTTP Response"?

Q: What is the format/structure of HTTP Requests and Responses?

Sniffing Browser HTTP Requests and Responses
--------------------------------------------

Since HTTP is a text-based protocol, you can use "netcat" to connect
directly to an HTTP server, send a simple Request, and see what responses
come back.  Note the need for a blank line to end the Request:

 *  $ nc -v google.ca 80
    google.ca [64.233.161.104] 80 (www) open
 *  GET / HTTP/1.0

    HTTP/1.0 302 Found
    Location: http://www.google.ca/
    Cache-Control: private
    Set-Cookie: PREF=ID=4bacaba254d7fab1:TM=1174172556:LM=1174172556:
       S=F5pnjX7gt4IYGP2n; expires=Sun, 17-Jan-2038 19:14:07 GMT;
       path=/; domain=.google.com
    Content-Type: text/html
    Server: GWS/2.1
    Content-Length: 218
    Date: Sat, 17 Mar 2007 23:02:36 GMT
    Connection: Keep-Alive

    <HTML><HEAD><meta http-equiv="content-type"
       content="text/html;charset=utf-8">
    <TITLE>302 Moved</TITLE></HEAD><BODY>
    <H1>302 Moved</H1>
    The document has moved
    <A HREF="http://www.google.ca/">here</A>.

Q: How can I use netcat to pull a Response from a remote HTTP server? 

To see what lines a browser sends to an HTTP server, you can use Ethereal;
or, for a quick dump, just use netcat on a spare port (e.g. 55555)
and have the browser access the port via http://localhost:55555/foobar :

Start a fake netcat HTTP server on a spare port, e.g. 55555,  then start
up your browser and connect to http://localhost:55555/foobar and see
what your netcat server reports:

 *  $ nc -v -l -p 55555 localhost    # Debian/Ubuntu
 *  $ nc -v -l localhost 55555       # RedHat/Mandrake
    connect to [127.0.0.1] from localhost [127.0.0.1] 40757
    GET /foobar HTTP/1.1
    Host: localhost:55555
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
        Gecko/20060216 Debian/1.7.12-1.1ubuntu2
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
        text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: en-ca,en-us;q=0.9,en-gb;q=0.7,en;q=0.6,fr-ca;q=0.4,
        fr-fr;q=0.3,fr;q=0.1
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive

At this point, you can type into the fake HTTP server netcat session
and send HTTP Response lines back to your browser:

 *  HTTP/1.1 200 this is my reply to the browser
 *  Content-Type: text/plain
 *
 *  ab
 *  cd
 *  ef
 *  gh
 *  ^C (interrupt)

Your browser will show the above text.

Q: How can I use netcat to show a Request from an HTTP client? 

Fetching a raw web page: wget
-----------------------------

You can use "wget" to fetch the raw HTML from a web page, and options
also let you see the header lines:

   $ wget http://idallen.com/
   $ wget -O output_file -S http://idallen.com/
   $ wget -O output_file --save-headers http://idallen.com/
   $ wget --header="Host: teaching.idallen.com" http://idallen.com/

Q: How can I download the raw HTML from a web page to my current directory?

HTTP is stateless; need session tracking
----------------------------------------

Unlike protocols such as SMTP, FTP, TELNET, etc., HTTP is completely
"stateless".  Nothing in the protocol links one request with another.
Any need for "state", e.g. login credentials, shopping cart data, etc.,
has to be done outside the protocol.

http://publib.boulder.ibm.com/infocenter/wchelp/v5r6m1/index.jsp?topic=/com.ibm.commerce.admin.doc/concepts/csesmsession_mgmt.htm
 "Web browsers and e-commerce sites use HTTP to communicate. Since
  HTTP is a stateless protocol (meaning that each command is executed
  independently without any knowledge of the commands that came before
  it), there must be a way to manage sessions between the browser side
  and the server side."

http://java.sun.com/blueprints/qanda/client_tier/session_state.html
 "What are the client-tier mechanisms for storing session state?"
  - cookies
  - URL rewriting
  - hidden form fields
 "We do not recommend storing session state directly on the client using
  URL rewriting.  [...]  This section describes how to store session state
  directly on the client for those who choose to ignore these guidelines."
 "We do not recommend storing session state directly on the client
  using cookies. [...] This section describes how to store session state
  directly on the client for those who choose to ignore these guidelines."

http://java.boot.by/wcd-guide/ch04s04.html
  "Given a scenario, describe which session management mechanism the
   Web container could employ, how cookies might be used to manage
   sessions, how URL rewriting might be used to manage sessions, and
   write servlet code to perform URL rewriting."

http://www.brics.dk/~amoeller/WWW/javaweb/sessions.html
  - URL rewriting
  - hidden form fields
  - cookies

Q: Why is session tracking needed on top of HTTP?

Q: What is an HTTP "session"?

Q:  Name and describe briefly two of three possible ways to implement
    implicit HTTP session tracking

Reading the HTTP RFC 2616
-------------------------
  http://tools.ietf.org/html/rfc2616
  ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt
  Standards: http://www.w3.org/Protocols/
  Errata:  http://skrb.org/ietf/http_errata.html
           http://purl.org/NET/http-errata
  Issues: http://greenbytes.de/tech/webdav/draft-lafon-rfc2616bis-issues.html
  Mail Archives: http://lists.w3.org/Archives/Public/ietf-http-wg/

  - HTTP is usually over TCP/IP, but any reliable protocol will do (p.13)

Q:  Does HTTP require a reliable protocol, or can it run over something
    unreliable such as UDP?

  - 1.0 required separate connections per request
  - 1.1 big change: allows chaining multiple requests per connection (p.14)

Q:  What big change did HTTP 1.1 bring to the HTTP "one connection per
    request" model of HTTP 1.0?

p.15
- ABNF extended with a "#rule" for comma-separated lists:
  ( *LWS element *( *LWS "," *LWS element ))  becomes  1#element
- implied *LWS can appear between any ajacent tokens or strings in the grammar

Q: Describe what this ABNF HTTP rule means:   2#3("foo")

p.15-16
- HTTP ABNF grammar is unaffected by LWS between tokens
- HTTP 1.1 lines can continue ("fold") onto multiple lines
  if the continuation line begins with a space or horizontal tab
- the only CRLF allowed is part of a continuation line
- if you want a real CRLF, or a non-ISO-8859-1 character, in a header
   field, encode it as RFC2047 (MIME)

Q: How can you fold a long line in HTTP 1.1?

p.17
- must double-quote special characters used in message headers
- some fields allow comments in parentheses ()

Q: What do HTTP comments look like in message headers?

  - unlike SMTP, HTTP has a version number!  (p.17)

  - URI "absolute" vs. "relative" paths (p.19, 36):

   "URIs in HTTP can be represented in absolute form or relative to
    some known base URI [11], depending upon the context of their use.
    The two forms are differentiated by the fact that absolute URIs
    always begin with a scheme name followed by a colon." p.19

 An Absolute URI starts with "http:" and a Relative URI is anything else.
 Inside a web page, Relative URIs can have some forms not allowed in an
 HTTP Request.  For the HTTP Request, Section 5.1.2 says you only have
 two real choices (the leading slash is required on the Relative URI):

     Absolute URI:  http://idallen.com/foo.txt
     Relative URI:  /foo.txt                  # an absolute path

    - proxy servers require ("MUST") absolute URIs ("http://...") (p.36)
    - note that "absolute URI" is not the same as Unix "absolute path";
    - for a Request, a "relative URI" must be an "absolute path" and
      start with a slash

  "To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies."

Q: Give examples of HTTP absolute and relative URIs used in Requests.

Q:  Can a relative Request-URI (client Request to server) begin without
    a slash, i.e. can it be a relative pathname "foo.html"?  (5.1.2 p. 36)

Q: Can an HTTP client request an empty URI?  (5.1.2)

Q: T/F The HTTP is moving towards always using absolute URI's.  (p.37)

  - path part of URI is case-sensitive; the host and scheme names are not (p.20)

   "When comparing two URIs to decide if they match or not, a client
    SHOULD use a case-sensitive octet-by-octet comparison of the entire
    URIs, with these exceptions:" p.20

Q: Which parts of an absolute URI are case-sensitive?

  - The HTTP protocol does not place any a priori limit on the length of a URI.
    - server may issue 414 (Request-URI Too Long) status (p.19)

Q: What is the maximum length of a URI, as given in the HTTP spec?

  - HTTP headers can describe:
    - "content encoding" - a property of the original entity (p.23)
      - e.g. "gzip"
    - "transfer coding" - a property of the HTTP message (p.24)
      - e.g. "chunked" (transfer content in separate chunks, p.25)
      - may change how the entity is transferred

Q:  What is the difference between the "content encoding" header and
    the "transfer coding" header?

  - HTTP relaxes CRLF rule - allows consistent CR or LF or CRLF in text
    (but not in control sequences!) - 3.7.1 p.27

Q: T/F HTTP permits a client to send just CR or LF when communicating with
   an HTTP server (e.g. when sending a GET or HEAD request).

  - HTTP Request/Response messages do not use SMTP "continuation" method
    - message headers continue until an empty line: CRLF CRLF  (p.31)

Q:  T/F The same generic HTTP message type is used both to send messages
    from client to server and from server to client. (section 4.1)

Q:  How do HTTP clients and servers detect the end of a series of message
    header fields (section 4.1)?

Q:  Is the CRLF at the end of the message headers optional?

  - leading empty lines preceding a Request or Response SHOULD be ignored
    (section 4.1, p.31)

Q:  Determine if google.ca, yahoo.ca, and facebook.com adhere to the
    above leading-blank-line SHOULD clause in section 4.1, p.31
    - nc -v google.ca http   OR   telnet google.ca http

  - multiple message-header fields with the same name are allowed
    - but only if the entire field-value is a comma-separated list
    - should behave as if they were all on one long field  (p.32)

Q:  T/F You can always send multiple identical message header fields; the
    HTTP protocol says they will be concatenated.

  - message body MUST NOT be included unless specifically allowed (p.33)
    - responses to "HEAD" MUST NOT include a message body (p.33)

Q: T/F All HTTP Responses may include an optional message body.

  - HTTP Request and Response messages have the same general format:

        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

       Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

  - "general header" fields apply to the message, not to the entity
    being transferred, and they can only be extended by a protocol
    version change  (p.35)

  - "request header fields" - section 5.3 p.38
    - can only be extended with a protocol change

  - "response header fields" - section 6.2 p.39
    - can only be extended with a protocol change

  - unknown fields are treated as "entity header" fields
    - you can have custom "entity header" fields without a protocol change

Q: T/F HTTP "general header fields" can appear in both Requests and Responses

Q: T/F Unrecognized HTTP header fields are presumed to apply to the
   entity being transferred; they become "entity header" fields

  - unlike SMTP (HELO and helo), the HTTP "method token" (e.g. "GET") is
    case-sensitive and must be UPPER CASE ONLY (p.36)
  - but HTTP header field names in HTTP messages are not case-sensitive! (p.31)

Q: T/F HTTP allows the use of either "HEAD" or "head" in a Request Line

  - servers MUST support at least GET and HEAD (p.36)

Q: What method tokens are the minimum required of an HTTP server?

  - A big change made from HTTP 1.0 to HTTP 1.1 was the requirement
    that HTTP 1.1 Requests MUST include the "Host:" header to indicate the
    network location of the web server with which you want to communicate.
    (5.1.2 p.37, 9.0 p.51, 14.23 p.129, 19.6.1.1 p.171)

  - With the HTTP 1.1 "Host:" header, a single IP address can now serve
    multiple different web sites, each of which is at the same IP address
    but has a unique network location.

  - the network location in an absolute URI over-rides the "Host:" header (p.38)

  - an unrecognized network location MUST produce a 400 Response

Q: If a client Request contains a host name in both the URI and the
   Host: header, which one has priority?

Q:  T/F If a URI or "Host:" header field specify a host name that is not
    recognized on this server, the server MUST forward the request to the
    other host name.  (5.2 p.38)

Q: List the names of the mandatory request header field(s) for HTTP 1.1

Q:  T/F If you give the host name in a URI using HTTP 1.1, you don't need
    to send the Host: header field, the name in the URI is sufficient.

HTTP Status Code and Reason Phrase - section 6.1.1 p.39
----------------------------------
  - a 3 digit Status Code, machine-readable, followed by a human Reason Phrase
  - only first digit has an assigned meaning (one of five) p.40
  - five "classes" of response, based on the first digit (p.40)

     - 1xx: Informational - Request received, continuing process

      - 2xx: Success - The action was successfully received,
        understood, and accepted

      - 3xx: Redirection - Further action must be taken in order to
        complete the request

      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled

      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request

Q: What are the five possible meanings of the first digit of an HTTP response?

Q:  T/F The Reason Phrases given in the HTTP RFC are recommendations
    only; they MAY be changed or replaced with local equivalents without
    affecting the protocol.

Q:  T/F HTTP 1.1 clients do not need to understand the meaning all of the
    registered three-digit HTTP 1.1 status codes.

Q: T/F An HTTP client MUST understand all five classes (first digit) of
   Status Codes.

Q:  If an HTTP server returns an unrecognized status code to a client,
    what SHOULD the client do with the response?  (6.1.1 p.41)

Entity (section 7 p.42)
------
  - the "entity" is the thing being transferred, e.g. image, text, etc.
  - "entity headers" give information about the entity being transferred
    - may include "extension header" fields
    - unrecognized extension headers SHOULD be ignored
  - entity body has a length header and so is 8-bit clean (unlike SMTP)
    - but a transfer coding (chunking) may have been applied to assist transit

  - The sender of an HTTP 1.1 message SHOULD give the Content-Type
    - but if not (and only if not), the recipient MAY guess it by inspection
      (7.2.1 p.43)

Q:  T/F In the HTTP 1.1 protocol, senders MUST provide the entity
    Content-Type header field.

Q:  T/F A recipient may over-ride the Content-Type by inspecting the
    entity being transferred (or its URI).

Q:  If no Content-Type is specified, what type is assumed?  (7.2.1)

  - the entity-Length of a message is calculated *before* transfer
    encodings have been applied (i.e. it is the actual length of the
    entity, regardless of how it might be altered to be transferred)

  - The Content-Length header, if present, MUST represent *both* the
    entity-length and the actual transfer-length.  (4.4 p.33)

  - You MUST NOT send a Content-Length field if you apply a Transfer
    Encoding (because the Transfer Encoding might change the size).  If a
    Transfer-Encoding field is present, you MUST NOT send Content-Length
    (because the Transfer Encoding method will specify the length).

Q:  T/F The Content-Length, if present, is both the real size of the item
    being sent and the size of the actual data being transferred.

Persistent Connections (HTTP 1.1 - section 8.1 p.44)
---------------------------------
  - a significant upgrade from HTTP 1.0 - Persistent Connections
    - HTTP 1.1 connections default to persistent, even upon error (8.1.2)

  - persistent TCP connections have many advantages:
    - fewer TCP handshakes
      - reduced CPU, memory, latency
    - allow pipelining multiple requests without waiting for responses
    - longer connections allow better TCP congestion control
    - allows HTTP to evolve more gracefully
      - errors don't cause the connection to close
      - no penalty for trying a feature then dropping back to previous version

Q: T/F HTTP implementations MUST implement persistent connections.  (8.1.1)
Q: T/F A persistent connection MUST drop on an error condition.  (8.1.2)
Q: Describe three of four advantages of persistent TCP connections (8.1)

- a "Connection:" header field can ask for explicit connection closing:
  Connection: close

Q: How can you signal the end of an HTTP 1.1 persistent connection?

Q:  T/F You signal the end of an HTTP session using the same keyword as
    SMTP - QUIT.

  - persistent connections require that all messages have a self-defined
    message length, so you know where the next message begins - you
    can't just end the message by closing the connection

Q: Why do persistent connections need message lengths?

  - clients should not pipeline non-idempotent methods or non-idempotent
    sequences of methods, to avoid inconsistent state if the connection drops
    in the middle and the same request has to be sent again

Q: Why not pipeline non-idempotent methods?  (8.1.2.2 p.46)

  - HTTP does not define any time-out for persistent connections
    (actually, I can't find any time-out for *anything*!)
    - connection close events may happen at any time (asynchronous)
  
  - clients SHOULD limit to 2 the number of persistent connections to a server

Premature Server Close - 8.2.4 p.50
----------------------

  - an issue with Internet protocols is: if the connection drops, when
    and how often do you try to get it going again?  Try too often and
    you may contribute to network congestion.

  - HTTP "MAY" use "binary exponential backoff" of T = R * 2**N (p.50)

Q: T/F HTTP client MAY double their wait times on each retry against
    an HTTP server.

HTTP Methods - section 9 p.51
------------

 "Implementors should be aware that the software represents the user in
  their interactions over the Internet, and should be careful to allow
  the user to be aware of any actions they might take which may have an
  unexpected significance to themselves or others."  p.51

  - safe methods should not have side-effects p.51
    - GET and HEAD "SHOULD NOT" have any effect other than retrieval
    - the user did not request the side-effects, even if they happen

 "Methods can also have the property of "idempotence" in that (aside
  from error or expiration issues) the side-effects of N > 0 identical
  requests is the same as for a single request. The methods GET, HEAD,
  PUT and DELETE share this property. Also, the methods OPTIONS and
  TRACE SHOULD NOT have side effects, and so are inherently idempotent." p.51

  - idempotent methods may have side-effects, but doing them once or
    more than once should not make a difference
    - e.g. GET, HEAD, PUT, DELETE are idempotent (can be done repeatedly)
    - OPTIONS and TRACE never have side-effects, are idempotent

  - a *sequence* of methods may not be idempotent, even if each method is:
    - "A sequence is idempotent if a single execution of the entire sequence
      always yields a result that is not changed by a reexecution of all, or
      part, of that sequence."
    e.g.  "PUT, DELETE"  is not an idempotent sequence because partial
    execution (e.g. just PUT) doesn't give the same effect as "PUT, DELETE"

  - A sequence made up entirely of methods that never have side effects is
    idempotent, by definition

Q: Define HTTP "safe" and "idempotent" methods.  What do they mean?

Q: Give examples of HTTP "safe" methods.

Q: Give examples of HTTP "idempotent" methods.

Q: T/F A sequece of idempotent methods is always itself idempotent.

GET - section 9.3 p.53
---

 "The semantics of the GET method change to a "conditional GET" if the
  request message includes an If-Modified-Since, If-Unmodified-Since,
  If-Match, If-None-Match, or If-Range header field."

 "The semantics of the GET method change to a "partial GET" if the
  request message includes a Range header field."

Q: Explain what is a "conditional GET"?

Q: Explain what is a "partial GET"?

HEAD - section 9.4 p.54
----

 "The HEAD method is identical to GET except that the server MUST NOT
  return a message-body in the response."

Q: What is the difference between the message headers returned by GET and HEAD?


HTTP security
-------------

- RFC 2616 was updated by 2817 to add Transport Layer Security - TLS
  http://tools.ietf.org/html/rfc2817
  ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt

  - 1997 meeting deprecated the practice of separate secure ports
     (having separate ports halves the number of usable ports!)

  "Parallel well-known port numbers have similarly been
   requested -- and in some cases, granted -- to distinguish between
   secured and unsecured use of other application protocols (e.g.  snews,
   ftps). This approach effectively halves the number of available well
   known ports.

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security [6] to an open
   HTTP connection."

Q:  Why does the IETF deprecate the use of separate port
    numbers for secure versions of Internet protocols?

Coding an HTTP server (Java)
----------------------------
HTTP RFC: http://tools.ietf.org/html/rfc2616

W3C Java server (HTTP 1.1): Jigsaw
    http://www.w3.org/Jigsaw/

A working Java HTTP server with basic functionality (in 145 lines)
is available here:

  http://www.brics.dk/ixwt/examples/FileServer.java

  - this version does not adhere to the HTTP RFC in many respects
  - needs comments on functionality (not on how Java works)
  - has many "public" items that should be made private
  - may be missing things such as closing opened files...

  (Older version:  http://www.brics.dk/~amoeller/WWW/javaweb/index.html )

An overview of TCP, HTTP and servers using Java:
  http://www.brics.dk/ixwt/http.pdf

Sun Guides/Tutorials on Java networking (mostly client side):
  http://java.sun.com/j2se/1.5.0/docs/guide/net/overview/overview.html
  http://java.sun.com/docs/books/tutorial/networking/index.html
  http://java.sun.com/docs/books/tutorial/networking/urls/index.html

java.net references:
  http://java.sun.com/j2se/1.5.0/docs/api/java/net/package-summary.html

java.net intro
  http://www.brics.dk/~amoeller/WWW/javaweb/javanet.html

Java 5.0 (also known as 1.5) package documentation:
  http://java.sun.com/j2se/1.5.0/docs/
  http://java.sun.com/j2se/1.5.0/docs/api/
    - java.io.File, java.lang.String, etc.

Java Notes (from a non-Java programmer)
----------

* On returning a pair of strings from a function

  I suggested that your HTTP server error function take two input strings.
  The first string is the Status Code and Reason Phrase from the HTTP RFC.
  The second string is text to put into the Message Body of the Response,
  giving more detail on the error, e.g.:

     "404 Not Found"
     "The Request /nosuchfile.html was not found on this server."

* How to return a pair of strings from a function in Java:

    public class IanStrings {
        private String[] foo() {
            return new String[] { "string one", "string two" };
        }
        public static void main(String[] args) {
            IanStrings istr = new IanStrings();
            String[] result = istr.foo();
            if (result != null) {
                System.out.println(result[0] + " and " + result[1]);
            }
        }
    }

* On setting and using the setSoTimeout method

  - the action of using the method to set a time-out may raise a socket
    I/O exception, at the time you set the time-out (you need a try/catch)
  - later, when the timer triggers, it will raise the SocketTimeoutException
  - the above are different exceptions and will occur in different
    places in your program (and you need different try/catch for them)
  - to set the time-out, you need to know exactly where your HTTP server
    blocks waiting for input (which is the same place as all your
    previous servers)

Eclipse IDE demo
----------------
 - see also the NetBeans IDE from Sun

1. Create a new project (Java application)
2. Set your Java compiler from "1.4" to "5" when creating
3. Import your FileServer.java file

4. Open the project
5.   Open the (default package)
6.     Right click on the FileServer.java name and,
       choose "Run as..." and then "Run..."
-OR-
4. Select the project
5.   Select the drop-down list on the Green Arrow button
6.     Select "Run..."

7. Open the "Java Application" drop-down arrow
8.   Choose your application name (FileServer)
9.     Choose the Arguments tab
10.      Enter your Program (command line) arguments
11. Push Apply
12. Push Run (or the Green Arrow)
    See the console output window at the bottom of the screen.
13. Push the red square to kill the application.
    See "<terminated>" in the console window

- hold your cursor over any word to get help on that word
- use F2 to lock focus on the help and allow scrolling