[cse491] reading complete requests

Joe Amenta amentajo at msu.edu
Fri Oct 2 19:08:53 PDT 2009


After doing a little research, for this project, we must use
Content-Lengthto determine the size of the
POST body and put the burden of supplying that field on the client.  Source:

http://www.w3.org/Protocols/HTTP/1.0/spec.html#BodyLength

When an Entity-Body is included with a message, the length of that body may
> be determined in one of two ways. If a Content-Length header field is
> present, its value in bytes represents the length of the Entity-Body.
> Otherwise, the body length is determined by the closing of the connection by
> the server. Closing the connection cannot be used to indicate the end of a
> request body, since it leaves no possibility for the server to send back a
> response.  Therefore, HTTP/1.0 requests containing an entity body must
> include a valid Content-Length header field.  If a request contains an
> entity body and Content-Length is not specified, and the server does not
> recognize or cannot calculate the length from other fields, then the server
> should send a 400 (bad request) response.


1) since we're implementing a subset of HTTP/1.0, we will have
Content-Length in well-formed POST requests.  (read the last line above for
what to do if the request is not well-formed)
2) even if we were to implement the close-the-connection way of determining
Content-Length, we would have no connection open to send back the response.

Hope this helps,
--Joe

On Fri, Oct 2, 2009 at 9:04 PM, Joe Amenta <amentajo at msu.edu> wrote:

> Example request:
>
> GET /form.cgi?username=mille449&password=saved HTTP/1.0
>
> The query string in that request would be
> "username=mille449&password=saved", or in other words, everything following
> the first "?" in the URL.
>
> As for the example code, yes, that would not read the POST data... perhaps
> the intent was just to show a way to handle the simple case, so that we can
> build off of it?  In any case, yes, that example code will fail to read in
> POST data, thus it should probably not get full credit.
>
> To read until the request is complete... this is an example of something
> that we can figure out through investigation.  One way to go about this
> would be to use form.html from way back in HW1.  Set the "method" to point
> to your web server, and then use print statements to figure out what the
> data looks like when it comes in.  (Might be useful to use repr() on the
> incoming data to see exactly what it looks like)
>
> I don't know what "end of request" will look like myself (though I have a
> couple of guesses) so at this point I can't be any more helpful than that.
>
> --Joe
>
>
> On Fri, Oct 2, 2009 at 5:58 PM, Tim Miller <mille449 at msu.edu> wrote:
>
>> Titus,
>>
>> In the assignment for hw4 you specify:
>>
>> The server should respond to both GET and POST requests, and should
>> read and ignore any GET query strings and POST data.
>>
>> However in your example code you have a line that looks like this:
>>
>> if '\r\n\r\n' in data_so_far:  # complete GET request - respond & close
>>
>> If I understand correctly, the server would stop receiving after the
>> first '\r\n\r\n' and would not read the POST data, so how do I read
>> until the request is complete, assuming there is no Content-Length
>> header?  Also, how are GET query strings specified again?  I can't
>> seem to find it anywhere.
>>
>> Thanks
>>
>>
>> --Tim
>>
>> _______________________________________________
>> cse491-fall-2009 mailing list
>> cse491-fall-2009 at lists.idyll.org
>> http://lists.idyll.org/listinfo/cse491-fall-2009
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/cse491-fall-2009/attachments/20091002/432bad12/attachment.htm>


More information about the cse491-fall-2009 mailing list