indexes

Here's a gdb exercise to help you find the problem in indexes.

1. create an index.html file in your public directory. It can be a simple text file that says "I am index.html", but it must be named properly.
2. start a gdb session in a terminal gdb ./server
3. set a breakpoint at indexes break indexes
4. run public to "run" server; you will see the "listening on port" message
5. open another terminal session and issue a curl request like so curl -i http://localhost:8080/. It won't do anything, because your gdb/server over in the other terminal is waiting at the breakpoint.
6. back in the gdb terminal, set a break point at the line indexes will return to (something like break 229 but verify that with your server source).
7. step through and inspect vars as desired. (use n not s so it does not step into the string functions).
8. When it returns to main (reaches that second break), inspect index. Probably not the value you were expecting.

Here's the problem in indexes. From the spec/instructions:

this function should dynamically allocate memory on the heap for the returned string

Where are you allocating either of the strings you are returning? And you know exactly how many bytes to allocate for, you should not use "constants" (think strlen). And don't forget to allocate a spot for the null-terminator. And remember strcat will handle null-termination for you, you shouldn't do an explicit set. And don't forget to free appropriately.

You'll probably want to remove the index.html file when you're done with gdb debugging, so that server goes back to listing the contents of public, making your browser testing easier.

load

Is it only failing on image files? Here's a gdb exercise to help you troubleshoot.

1. start a gdb session in a terminal gdb ./server
2. set a breakpoint at load break load
3. run public to "run" server; you will see the "listening on port" message
4. in another terminal tab, find out how many bytes cat.jpg is. If you issue a ls -al cat.jpg command, you will see the number of bytes in the result
   (-rw-rw-r-- 1 ubuntu ubuntu 26860 Oct 24 2015 cat.jpg 26860 in this example).
5. in a browser, send a request for cat.jpg
6. gdb/server should break at the load breakpoint you set.
7. set another break point at this line *length = i;
8. c continue to reach that break, inspect the contents of i. It should match the number of bytes from step 4.

I suspect it will not. This problem is much more subtle. It has to do with how fgetc casts data, and what EOF is. Here is an explanation. Basically, it gives a "false eof" because a valid image byte will become "EOF" to the system when cast as a char. One possible solution would be to declare and int var and use that for the fgetc result (and the while test), and set buffer[i] to it.

indexes

Here's a gdb exercise to help you find the problem in indexes.

1. create an index.html file in your public directory. It can be a simple text file that says "I am index.html", but it must be named properly.
2. start a gdb session in a terminal gdb ./server
3. set a breakpoint at indexes break indexes
4. run public to "run" server; you will see the "listening on port" message
5. open another terminal session and issue a curl request like so curl -i http://localhost:8080/. It won't do anything, because your gdb/server over in the other terminal is waiting at the breakpoint.
6. back in the gdb terminal, set a break point at the line indexes will return to (something like break 229 but verify that with your server source).
7. step through and inspect vars as desired. (use n not s so it does not step into the string functions).
8. When it returns to main (reaches that second break), inspect index. Probably not the value you were expecting.

Here's the problem in indexes. From the spec/instructions:

this function should dynamically allocate memory on the heap for the returned string

Where are you allocating either of the strings you are returning? And you know exactly how many bytes to allocate for, you should not use "constants" (think strlen). And don't forget to allocate a spot for the null-terminator. And remember strcat will handle null-termination for you, you shouldn't do an explicit set. And don't forget to free appropriately.

You'll probably want to remove the index.html file when you're done with gdb debugging, so that server goes back to listing the contents of public, making your browser testing easier.

load

Is it only failing on image files? Here's a gdb exercise to help you troubleshoot.

1. start a gdb session in a terminal gdb ./server
2. set a breakpoint at load break load
3. run public to "run" server; you will see the "listening on port" message
4. in another terminal tab, find out how many bytes cat.jpg is. If you issue a ls -al cat.jpg command, you will see the number of bytes in the result
   (-rw-rw-r-- 1 ubuntu ubuntu 26860 Oct 24 2015 cat.jpg 26860 in this example).
5. in a browser, send a request for cat.jpg
6. gdb/server should break at the load breakpoint you set.
7. set another break point at this line *length = i;
8. c continue to reach that break, inspect the contents of i. It should match the number of bytes from step 4.

I suspect it will not. This problem is much more subtle. It has to do with how fgetc casts data, and what EOF is. Here is an explanation. Basically, it gives a "false eof" because a valid image byte will become "EOF" to the system when cast as a char. One possible solution would be to declare an int var and use that for the fgetc result (and the while test), and set buffer[i] to it.