Skip to content
GitLab
  1. 23 Nov, 1999 2 commits
  3. 22 Nov, 1999 1 commit
  5. 20 Nov, 1999 1 commit
  7. 18 Nov, 1999 2 commits
  9. 17 Nov, 1999 2 commits
  11. 16 Nov, 1999 1 commit
  13. 14 Nov, 1999 1 commit
  15. 09 Nov, 1999 1 commit
  17. 05 Nov, 1999 2 commits
  19. 04 Nov, 1999 2 commits
  21. 02 Nov, 1999 1 commit
  23. 01 Nov, 1999 2 commits
    • dgaudet's avatar
      i asked a friend who does interface design to comment on the "it worked" · 450c9faa
      dgaudet authored 
      page.  i liked what he had to say.

> From: James Home <jim@vagabondage.com>
>
> reading over the page, it appears that the primary audience for the
> page is the person who's installing Apache. this doesn't really make
> sense though; the only information it's necessary to convey to that
> person is that the server is working, and the simple presence of the
> page does that.  sure, there are the links to the Apache homepage and
> to documentation, but those don't require much prominence; if someone
> is looking for them, they're easy to find.
>
> I'd say that the primary audience for the *information* on the page
> is the poor befuddled user who doesn't know an Apache helicopter from
> an Apache web server and wants to know what happened to the website
> they've spent weeks working on.
>
> so how is a user like that going to experience the page?
>
> - a logo that they don't recognize at the bottom of the page
> apparently claiming responsibility for it;
>
> - some confusing "It Worked!" message at the top of the page;
>
> - a somewhat threatening and vague message that, despite the fact
> that this page is all about this mysterious software called Apache
> (note that it isn't explained that Apache is web server software
> until the very last line of small text), Apache isn't responsible for
> the site, and I should "contact the administrator of the site
> involved" (of course, if I was an end user who didn't understand how
> web servers work, I would assume *I* was the administrator of my
> site, leaving only this mysterious organization to contact).
>
> - clicking on the most prominent link takes me to another page that
> doesn't specifically mention web servers.  there's a contact link
> though, which takes me to the page with the email address and Sally's
> phone number.
>
> I did a quick mockup to demonstrate how I think this might work better:
>
> http://www.vagabondage.com/~jim/apache/worked2.html

Submitted by:	James Home <jim@vagabondage.com>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@84086 13f79535-47bb-0310-9956-ffa450edef68
      450c9faa
    • Tony Finch's avatar
      I had to chase too many links to find the content negotiation docs · 2b438087
      Tony Finch authored 
      just now so this'll make it easier to get to.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@84085 13f79535-47bb-0310-9956-ffa450edef68
      2b438087
  25. 29 Oct, 1999 2 commits
  27. 28 Oct, 1999 3 commits
  29. 27 Oct, 1999 13 commits
  31. 22 Oct, 1999 1 commit
    • Bill Stoddard's avatar
      Apache for Windows can get caught in a tight loop whild handling CGI requests. Here's how: · 3fa11555
      Bill Stoddard authored 
      sendwithtimeout() sets  errno to EINTR on a timeout and returns SOCKET_ERROR (-1) to
the caller. The caller reissues sendwithtimeout, which then succeeds. errno is left set to
EINTR. Eventually,  another read is attempted on one of the CGI pipes (ap_bgets in mod_cgi,
or ap_send_fb_length) which goes down into ap_read. ap_read issues a Win32 ReadFile to read
from the pipe. If this read fails, it returns -1 to the caller. If errno
is still set to EINTR, the caller will retry the read and so the loop begins.

The solution is quite simple. buff.c relies heavily on errno. Anytime Win32 calls are used
in code that uses errno, we need to always, ALWAYS explicitly set errno when a Win32 system
call fails (via either errno = GetLastError() or errno = WSAGetLastError()). Since Win32
does not use EINTR, this problem should not occur.

PR: 3599 3971 4245 4430 4758 5171
Submitted by:	Thanks to Jim.Patterson@cognos.com who discovered the loopig section of
code.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x@84018 13f79535-47bb-0310-9956-ffa450edef68
      3fa11555
  33. 21 Oct, 1999 2 commits
  35. 13 Oct, 1999 1 commit