[ee122] bucket of questions

Carrell Killebrew 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.

> Thanks.
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122

More information about the ee122 mailing list