Skip to content
GitLab
  1. 21 Nov, 1996 11 commits
  3. 20 Nov, 1996 3 commits
  5. 19 Nov, 1996 1 commit
  7. 18 Nov, 1996 5 commits
  9. 17 Nov, 1996 5 commits
  11. 14 Nov, 1996 3 commits
    • brian's avatar
      Submitted by: Alexei Kosut · 7868fb8b
      brian authored 
      Here's a patch that provides a number of fixes to chunked
transfer-coded input when using get_client_block:

1) Correctly works with 1-byte reads (like content-lengthed reads,
which was fixed a week or so ago, this was not working.)

2) Fix "footer" reading. It now just calls get_mime_headers(), which
should work. This way, they're accessible to the server, as they
should be, though (unfortunately?) mod_cgi calls get_client_block too
late to pass it on to the CGI script. Unless anyone knows a way to
modify the environment of a child after you've forked it.

It also adds a few comments (there was one part it took me five
minutes to remember what the heck it was doing... and I wrote it. So I
figured I'd better throw in a comment). Anyhow, I think it's important
to make this work right, since it's an integral part of HTTP/1.1


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76979 13f79535-47bb-0310-9956-ffa450edef68
      7868fb8b
    • brian's avatar
      Reviewed by: Brian Behlendorf · 312f1555
      brian authored 
      Submitted by:	Paul Eggert <eggert@twinsun.com>

Fixes time zone problems.

Old behavior:

* When the time zone is not an integral multiple of 1 hour,
the logs report bogus UTC offsets.  E.g. if the time zone
is +0530 the reported UTC offset is +051800.

* If !defined(HAS_GMTOFF) && !defined(NO_TIMEZONE), when the
daylight-saving offset is not exactly 1 hour, the logs compute the UTC
offset incorrectly when daylight saving is in effect.

* If !defined(HAS_GMTOFF) && defined(NO_TIMEZONE), the code invokes
mktime twice, once on the output of localtime and once on the output
of gmtime, and subtracts the results.  This method is incorrect when
the time is near a daylight-saving shift boundary.  For example,
suppose we are in US Pacific time and the current time is 1996-10-27
00:00:00 local time, just before a daylight saving time shift.  The
correct UTC offset is -0700, but in this case get_gmtoff incorrectly
computes an offset of -0800, because mktime(gmtime(...)) applies
mktime to `1996-10-27 07:00:00' (actually a UTC time, not a local
time) and the UTC offset as of 1996-10-27 07:00:00 local time is -0800.

Here is a patch.  The key idea of the patch, which you'll find at the
end, is an idea stolen from INN 1.5b1: assume that we are no more than
24 hours away from UTC, which is a reasonable assumption (among other
things, Posix requires support only for -2400 through +2400 time
zones)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76978 13f79535-47bb-0310-9956-ffa450edef68
      312f1555
    • brian's avatar
      Reviewed by: Chuck Murcko · 768dcc5b
      brian authored 
      Submitted by:	Brian Behlendorf

Slight tweak to compress scoreboard bars from 6 to 4.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76977 13f79535-47bb-0310-9956-ffa450edef68
      768dcc5b
  13. 12 Nov, 1996 4 commits
  15. 10 Nov, 1996 2 commits
    • Ben Laurie's avatar
      Spelling misteaks. · fde0092d
      Ben Laurie authored 
      
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76972 13f79535-47bb-0310-9956-ffa450edef68
      fde0092d
    • Roy T. Fielding's avatar
      Fixed a bug in the header parsing code triggered when a continuation line · 0d4bc8d2
      Roy T. Fielding authored 
      is a single space: the entire header field above it was ignored and the
message terminated. This would normally only occur when cut-n-pasting from
an xterm, but it revealed a bunch of other problems with the way we were
looking for the request-line and header fields.  I fixed it by rewriting
the routines so that they would be more natural and not discard the
error conditions, and introduced a new routine to buff.* for looking
at the top of the input stream without changing it.

The good news is that we now handle input lines robustly and do not
puke when an extra CRLF is placed at the end of a POST request.
The bad news is that I have found several places where we should be
responding with 400 or 414 (Request-URI Too Long) messages when our
input buffer fills-up, but we have no apparent mechanism for die'ing
inside http_protocol.c.  For now I am just letting the input be truncated,
which is good enough for robust handling, but I would prefer to send an
error response so that the webmaster can know about the invalid
buffer-blowing attempts.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@76971 13f79535-47bb-0310-9956-ffa450edef68
      0d4bc8d2
  17. 08 Nov, 1996 2 commits
  19. 06 Nov, 1996 2 commits
  21. 04 Nov, 1996 2 commits