[ee122] Token failures; Command line arguments; Server to client data
Niels Joubert
niels at berkeley.edu
Tue Sep 25 23:31:54 PDT 2007
On token failures:
I'm having some trouble interpreting the spec. According to it, "for
invalid requests, proint out an error message indicating which token is
missing or illformed". This sounds like you parse from left to right,
until you get something that doesnt match. When that occurs, you print
an error message and stop.
A little further down, it claims "for each error encouteres, [it] should
print one of the corresponding error messages". This sounds like you
should keep parsing and print all the possible error messages. The case
i'm confused about is the following:
The server receives "/Research/Areas/OSNT/index.html HTTP/1.0"
Thus is parsing from left to right you encounter an "illformed method
token" that happens to be a perfectly well formed uri. Should you print
an error for method token, or keep going? An if you do keep going, i
assume you will now try to match the next part of the string, being
HTTP/1.0 to request-uri and also give a misformed request-uri error
message. Since the string is now at end, do you stop, or do you print
the error messages that corresponds with the rest of the unmatched data?
In a nutshell - should i parse left to right, using one regex at a time
and keeping track of where I am in the recieved string, and stop with an
error message on the first incorrect input, or is something more fancy
required?
Thanks!
-Niels
Lisa Fowler wrote:
> ---------------------------------------------------------
> TOKEN FAILURES/PATTERN MATCHING:
> ---------------------------------------------------------
>
> Our grading will use greedy token matching.
>
> e.g.
>
> GET/foo HTTP/1.0
>
> ---> Should return a valid method, but invalid pathname.
>
> However, for grading for this milestone, either will be fine.
>
>
> ---------------------------------------------------------
> COMMAND LINE ARGUMENTS
> ---------------------------------------------------------
>
> For the client:
>
> Part A requires command line arguments: http_client <server> <port>
> Part B SHOULD NOT USE command line arguments: http_client
>
> Therefore, since we are really targeting Part B, your final client
> should not use command line arguments.
>
>
> For the server:
>
> Part A: Specify the port on the command line: http_server <port>
> Part B: OPTIONALLY specify the port on the command line: http_server <port>
> DEFAULT to port 80 for the server.
>
>
> ---------------------------------------------------------
> SERVER-TO-CLIENT DATA
> ---------------------------------------------------------
>
> Upon receipt of a valid request, the server will both:
>
> (1) echo that request to the client over the network. This echoed
> request INCLUDES THE CRLF
>
> (2) print that request to stdout, followed immediately by the
> components of the request, per the PDF
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
More information about the ee122
mailing list