my server.c load and indexes functions are not working properly, and I'm not sure what's up. My parse and lookup functions pass all the tests. Any thoughts?

bool load(FILE* file, BYTE** content, size_t* length)

if (file == NULL)
    return false;

char* buffer = malloc(sizeof(char));
size_t i = 0;

int hold = 0;

while((hold = fgetc(file)) != EOF)
    buffer[i] = hold;
    buffer = realloc(buffer, sizeof(char) + (sizeof(char) * i));

*content = buffer;
*length = i;

return true;

char* indexes(const char* path)

char* path1 = malloc(strlen(path) + 10);
char* path2 = malloc(strlen(path) + 10);
strcpy(path1, path);
strcpy(path2, path);
char* php_extension = "index.php";
char* html_extension = "index.html";

strcat(path1, php_extension);
strcat(path2, html_extension);

if (access(path1, F_OK) == 0)
    return path1;
else if(access(path2, F_OK) == 0)
    return path2;
    return NULL;

1 Answer 1



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.


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.

  • Thanks for your help! I've updated my changes, and I am still getting a couple of errors. My code now passes almost all of the tests, but gets hung up on Requesting hello.php?name=Alice returns 200, text/html, and correct output; Requesting /test/ outputs /test/index.html; Requesting two files in a row (cat.html then cat.jpg) succeeds. Any thoughts? Aug 28, 2016 at 6:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .