Subject: [Tools-discuss] Re: Apache upgrade.

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Nov 2006 18:14:05 +0100

Henrik Levkowetz wrote:
 
> If you see any anomalies on the tools pages that might be caused
> by this, please let me know.

Sometimes http://tools.ietf.org/html/something fails, but it's okay
when I add www3 as in http://www3.tools.ietf.org/html/something

Frank

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Nov 2006 03:54:33 +0100

Hi Frank,

> when I add www3 as in http://www3.tools.ietf.org/html/something

Hmm.  Fails as in reporting Document not found, or an outright error
screen?

(It could be that the draft repository is incomplete in one of the
servers.)

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Nov 2006 18:15:23 +0100

Henrik Levkowetz wrote:

> Fails as in reporting Document not found, or an outright error
> screen?

Checking, the draft in question was
http://tools.ietf.org/id/draft-kucherawy-sender-auth-header-03.txt

s/id/html/ - ugh, that works today.  Tying www3: okay. www2: okay,
www1: okay.  Probably I somehow managed that it's now in the cache
everywhere.

Checking another old draft:
http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02

"Document contains no data" (but it works with www3).  Adding ".txt",
works.  That's _not_ the effect I had yesterday and sometimes before.

Trying more old drafts, not the wanted effect, but here:
http://www1.tools.ietf.org/html/draft-mengwong-sender-rewrite

document not found + additionally a 404 for the error document 
 
On www2: only a document not found, no additional missing err404.
On www3: same as www2

Now adding -01, same effect (now www1 doesn't claim that it has any
additional issue with the err404 document).  Adding -01.txt, still
no success.  Using www3 + id + explicit 01.txt: found.  Switching
from id to html: works.

Okay, that's plausible, if I use an exact name with id (not html)
on a specific server (especially www3), and then switch to ftml, 
it works.  

But that's probably no "apache upgrade" effect, we discussed a
similar effect some months ago, then you did something, I forgot
what, cleared the cache maybe, and it worked again everywhere.

Wild guess:  Your cache is too big for some odd race condition
somewhere, and www1 and/or www2 are more fragile than www3 wrt
this rare condition (?)

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Nov 2006 19:56:01 +0100

on 2006-11-14 18:15 Frank Ellermann said the following:
[...]
> document not found + additionally a 404 for the error document 

Aha.  Found this problem, fixed it.  A script which gradually deletes
old files in the /html/ cache also deleted the 404 handler script on
www1 [[ouch]] (but not yet on www2 and www3).

> no success.  Using www3 + id + explicit 01.txt: found.  Switching

Hmm. Weird.  Could this be a problem with the client-side casheing
not taking the full host name into consideration??

> what, cleared the cache maybe, and it worked again everywhere.

Right.  That was a cache issue, but I don't remember details.

> somewhere, and www1 and/or www2 are more fragile than www3 wrt

Could be.  In this case the primary problem was the disappearance of
the 404 handler on www1, but I can't explain the problems with www2
and www3.  I'll keep an eye out for this (and if you have further
ideas, I'd be glad to hear them).

Regards,

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Nov 2006 23:04:25 +0100

Henrik Levkowetz wrote:

> if you have further ideas, I'd be glad to hear them

New idea about the "document contains no data issue":  I started
with tools - html- rfc2298 getting this.  And a 404 for the same
query with "id" instead of "html".

Then I used www3.tools - html - rfc2298, and it worked.  It has a
link to 3798 (I wanted that number), clicking I got again the odd
"document contains no data", now for www3.tools - html - rfc3798.

At that point I figured that this issue is unrelated to tools vs.
www3.tools, but some ordinary timeout.  And testing that theory
by simply asking again for www3.tools - html - rfc3798 it worked.

And I recalled that we discussed this already months ago here, my
client sends a GET xyz HTTP/1.0, plus a Host: header field (older
clients are anyway doomed today).

Maybe it's an HTTP/1.1 303 vs. HTTP/1.0 302 issue.  Random test,
http://tools.ietf.org/html/rfc1357 (whatever, not 1234 :-), I got:

~~~ cut ~~~
HTTP/1.1 302 Found
Date: Fri, 17 Nov 2006 21:53:32 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.0 PHP/4.4.4-6 mod_perl/2.0.2 Perl/v5.8.8
Location: http://tools.ietf.org/html/rfc1357
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=US-ASCII

~~~ end ~~~

Well, that document obviously is empty, and it redirects me to the
location I've asked for, is that sane ?  Testing it for a third time
(about a minute later) I get RFC 1357.

RFC 2616 says that a 302 SHOULD contain a short document with a link
to the new location, the content-length 0 violates that.  It also
says that clients SHOULD detect infinite loops, a redirection to the
URL I've asked for might not work as expected.

Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 18 Nov 2006 11:08:43 +0100

Hi Frank,

on 2006-11-17 23:04 Frank Ellermann said the following:
...
> location I've asked for, is that sane ?

Humm, not really nice.  Fixed now; by testing if the URL and the redirect
location is the same, and if so the document is served directly with a
200 OK.

>  Testing it for a third time
> to the new location, the content-length 0 violates that.

Ok, should be fixed now.  Please check that the minimal document you
get back looks OK.

>  It also

Right.  This should be fine now, with the test mentioned above.

	Henrik