[ee122] Token failures; Command line arguments; Server to client data

[Richard Schmidt]

I made my program stop on first parse error. I didn't close the connection
from the parsing function, I just stopped parsing further.

Despite what people say, I like <goto>'s. They help in a non-OOP language
like ANSI C.
Rick


On 9/25/07, Niels Joubert <niels at berkeley.edu> wrote:
>
> 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
> >
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20070926/7f4617ab/attachment.html