[ee122] bucket of questions
dank at EECS.Berkeley.EDU
Sun Oct 28 17:01:39 PDT 2007
----- Original Message -----
From: benjlau at berkeley.edu
Date: Sunday, October 28, 2007 4:43 pm
Subject: [ee122] bucket of questions
> let's say we're the client and the server sends us a bad response
> and we
> decide to print an error message indicating that the response
> failed to
> parse. We just use Network Error I think? Or is that only for atomic
> network operations like socket() and connect()? Does the answer also
> apply to bogus status line and body (eg if chunked and rather than
> beinghex, we find alpha chars on the line for size).
You can say
ERROR -- Parsing Error: <what the server sent you>
> Let's say you are blocked from writing to a file on the client side
> afterdownloading from the server (maybe someone else is writing to
> it). This
> does not seem like a network error. Can we just make up a new
> error for
> cases which aren't network errors, so long as we're clear about it
> whenprinting to stdout?
Yes, the important thing is to have the word 'error' somewhere in what you print to stdout.
> The project write up says that The HTTP response message and any
> associated headers should be printed to standard output without any
> additional processing. Is this to be taken literally? Just start
> printing straight away? Because the write up also says that If the
> request does not succeed, your client should print the status code and
> associated text, such as:
> 403 Forbidden: /secret/diary.html
This was answered on the newsgroup already.
> But wouldn't this be redundant then, since we already printed out
> the HTTP
> response message? Also, when we print out the 403, should it be
> prefixedby Network Error-- or does it not count as an error but as
> a valid message
> that indicates a permissions denied on server side?
No, don't prefix it by anything. Just print out the line with 403 in it.
> For the server during Phase 1, we printed the components of the
> request,specifically the status line. Are we only printing the
> headers now? It
> doesn't seem to say to print the status line anymore.
I will only be checking if you print the headers, not checking to see if you print the status line.
> Back to the client, let us say that the server response has this:
> Connection: aserawt8a
It is an unrecognized header line, and it's not an error. Continue processing the request as per normal.
> Is this an error or should we default to closing the connection?
> In general, if we experience any kind of bad response parse, should we
> just automatically close the connection even though we originally
> stipulated a persistent connection, or should we keep it open?
The client can close a persistent connection whenever it wants. So if the client gets a bad response from the server, then it should close the connection.
> What content type does a directory have? I am thinking that we
> treat the
> ls contents as just text/txt.
A directory listing has content type text, like you guessed.
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
More information about the ee122