International Customized Server Error Messages

From 583daac7a5664c97587e01a7c94d75b1ca9a6553 Mon Sep 17 00:00:00 2001 From: Erik Abele Date: Sun, 2 Mar 2003 01:21:57 +0000 Subject: [PATCH] Bust 'em :) git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@98875 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/images/custom_errordocs.gif | Bin 23291 -> 0 bytes docs/manual/misc/custom_errordocs.html | 489 -------------------- docs/manual/misc/descriptors.html | 196 -------- docs/manual/misc/fin_wait_2.html | 387 ---------------- docs/manual/misc/footer.html | 5 - docs/manual/misc/header.html | 6 - docs/manual/misc/known_client_problems.html | 345 -------------- docs/manual/misc/tutorials.html | 211 --------- 8 files changed, 1639 deletions(-) delete mode 100644 docs/manual/images/custom_errordocs.gif delete mode 100644 docs/manual/misc/custom_errordocs.html delete mode 100644 docs/manual/misc/descriptors.html delete mode 100644 docs/manual/misc/fin_wait_2.html delete mode 100644 docs/manual/misc/footer.html delete mode 100644 docs/manual/misc/header.html delete mode 100644 docs/manual/misc/known_client_problems.html delete mode 100644 docs/manual/misc/tutorials.html diff --git a/docs/manual/images/custom_errordocs.gif b/docs/manual/images/custom_errordocs.gif deleted file mode 100644 index d566c5d891e5c574267fe715fc10706c5702b790..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 23291 zcmbq(Wl$VV7w+PVyM`nLcMC2FL4pK#54N}mx4`0yJ1i31-95OwySoS1Gk!sySv-L!2t{gJ3BioDLsL`yXJ0O0)1{Ox-4`A@tRfY-PCO=AZE*gL9gRbz&MnB z9Qq&JH|ufe>znELIQ!eXH|5Q5eEfC%Kdf)%+i>5IgI)p9*SC2559lj9=#?G%%KrNL zA5hRM2>J?oeH-u_rdKHF^(_Q%2>!nl^M5V;_bmV@Fkg7Ee?VYRa7ZX5EIcAIDmo@M zE)S?=?}zb)E%hI>JG-Cl1Y=Q%I*y#`E0o|P?ggkMS+R6MMs}I7)P&C ztUFkpH=M+7Jd`$Qzf}m!8Sm(Zo%Ig?{cEp*YQX3Ke_WfFC64K?8B*?hxuuUf)0Id$Yvu3H*A^@G zeF~Ta*;W^%2L*}Ng2=LZ~8wWJhbLJF;c9sT7yr0YEr;}bi!=XPniz&@kaAiguXiDmr2`@ zf)pFrz;=csICvt~X6|>m$kfGxkFIn@+*t0$ znYD9dE15i<+qu6&WSSPUC%Kp6bLZ+Lm@{Z0DXXQGM2k8lzNkRWs5&^{PMr(5*t&Qz zqp_?e6N0wiP@ibUYSQSKf1E|c+P~5=VJM}U6xB7mnd*UjSd_nFd2Ce2q%33BKDWnU zn-)U&OqpUd1Y!C6jmPt>hXAIrOXw)iGiVzy#?Nn=1qgF|@xNH8Iv~ubt4+qm9RNRruf@{%jA5#~AbbWfa{+k%- ze#6K0JKv^Cur4>8o$-nC>ab`JN$>Wd&BJaqcX`tu%(|R3hxc3L!$EG6t-yjR_Eg7F zX~Ws$ab-X2(@E{T?bB)Fe)-c`>)qMYc?SyH^F19X2oZ3a^UVwkn^f$;RI`95m8cx1o|4j zL=Kdry~qS(3m~EVxd+l+4q5QEQsB9|iA#LT4pN9WBI+&dWs;eMXr3$}(-HKcnZbWr*Lu&`IlKA4b-ijZ_x$otLL8FtC&o-{C&(d;4$Mw7fn*RH z3oqJXB$t*2X4oUpRTAVTYe2lrC-qG|#v+3&mkP~d@T;j(jD_qDBeB+yc5`*CsTYXC zYH(QY@iHmJjf_U;q3i6>A;~Iti`muUhfH)#3}NdoaTEQp*wkg>0=X%xnzW>aHeT`u z#y;2E4=wY7GM_mikdRx2s7A{8mB@JXhr6X2r0FIG+(nt8F|D3XgP zRxKcdwHH9+i#11!)ioA?g|;^(2ACy6t&DTk(3{d_3MTFOp}Be=(K6eJ65ahHpcB?c zx!Y)o{@u`g`{PZ8FJ`F$%8!LEvfIiKxl$wI;e|ed+p6e@QWLr#i$mJC)ybo!KU?-& z$2@LpGBL}{C4VeUL2qjd<;pA_T-5^dl=F+1wM7?tkLGxH({3B zbMyOck=->8NR(6Hq4@#D0UtWvmpc`Nb?s=+HxF|&AhzP^9eLcfz>jnw_E@c8ge0}@ zzCTB-4*Q}+J6W$lmc`9bHLpAp6?92+AhG$-ZLyOS*QuKC({vb`aO>Lf`G%5KsyGzZ zinZ0gCTxf7;kowjmI$8ElG zKhrB~H9nI|$&^ntSNLOX47rStt{|vP*?uzNns>_hM#KKqqIi#ZKQ`RO>&j<#z%+Dh zS}`?-fm&$Am+>e6uufuG)M%KWDq>0lsd;S-9R?gVRVAE$5m!P=nyHOEXQ9xTLsnhu z;jTwTefF8-wWF7Y{5W62ub_O0l81C6R3-0hrLa6_1SsxOn+58 zrNsd^aSNa`IgvJY5i91Z2EJ3oz>dIBS&*^iV`tjg9;$TlhU5X^O8#2ywM*+6Vur_R z2~%C`zaKIns;f*!7PD`!7Aop%?=m~p4=M~!CqWJD0adKODqhNl0@m^I1N%5zr-irN z#|h!TV>#x$dk=so;a?`{)sBZe@|@^`p?Fw(wS?)Wl7R~=Ypm%3e@loG--!T>v4(C^qLN#bIJ$AJq+**L=K z=on~8vPdLuTi8+OQwAMersOm)vqkA=t?J*@hUD_1ZihAod1wQ)yG%Dc5a ztsXwNnlJr|I5E@SYFDun9PQRquQKk~j-_>EWR12N_FS35Bj{)tg>8a8m-4d8JzRgS z*fcA^hRS(7HVtj;#ctEqxzG65T%#1y5On7JuuTP>EAIOczRuP0dhV!=pDh?|9BCw7 zUp2s1hJS8cW=3VjPPW-IA`9ffo!bkP2wlxvEe>C;IgX}|?0>#AG*%0wqj8v@?wRUMQBmgNYneFk^H2<^sP{iNYAaoFMb8=VpD z-ANW~PHBX5P{2%@0oxPcYYBJrS%3ZzxGi5eh0prJ3x3p^j^Et^*L?$|lXak3{`!Ud zswBc68+|l2gLZNP%y#*^5Ch&Niik-CnUVxM(qmgDf3r?D0UHGVY7F+03U=1~cEA;6 zz7QOs88Ukj?0aBy4hjih2wCwB`75g9e-IL{8M;6bnwT64<->C6)xa&#$|Qkg^FeYo zA^C2Q!emHsBcyZzf<+WiLKs%f7gnnoR__+pm>kyZrd`(Sygbi-55@kQ=vM((*q9wbMi zO{fjH8RA^%43TJz6h>ZaM%}ta-6uyqHby-!M8Py8RXQSF-7K>Abted;&b!^y=&-K_ zFt8q?aY$qE_+tpPVu;*hRB)n|gTld;dhL9uaFzPIInlTs(W7oL^eM57O|i_2v8)fV z#nCbFp`q~xew5O{Gbv#_04B9XELtWhJ88Tqf4sO>{CBMw&ZZayQjaZ-xN%;%V&Aw{ zHDNpo0Gfq~e|8|oEf6!56YDU+-XVSvkk}xS*kh1rl#*yk8qX;$C?e(f@c~HY=0|KF z_nu$oR>Px)2zA02purD^sF*-kmy|dGOGy5gPzFdeNg*xiNUkS^b{(u%knm!SlHpKv)I7~?8PoE7% z&pk}3+(_GShwf-)6c)vB-5Ut@#n|zE!@I~(N(nw^021HF_a-TO?8&Upe1An@3sFq) zDT-bW1pGx!>$`JmL3ZvBO&l3S$6QKZDoRUPOvbZJ-(*N9gk+IwC;qKWClJWkBh99? zM3+v<$h}R}$P4zr$Y3T*V1dab)h$|82mfFPStW2ud;kIAd;vctV};0aP!il;^F3K> zGesCu5<|(Q7@=WJSwxmu*u`1np()aj$;uG!G_5R>Z5~OP^dFEs14yo}KzfdJo)Tj| z74$8~I~HW9*T-|rK+6ZSon#8gG?Q>Cl2Pk_qc+>Ux~QTx#I-f0B5G%jAi8by*w-}t zLf1|=W6Ur-%8Px>HD5~C(9Sc4=E*;%3`(bbgrvzG<)x8jDQFYqG8SP#v!aXhOD&<+ z(2UTa>~HiQVdg+*j}jtt6TNw7f5}`}ku~J8#8(CgUdq9@hocDvh>+#-dw8H&0wZM7 zqaKUWWy<0hi(wRKc~h2o8QNtUkTR8}vOLC=WtpNS%c3I2@*j`sWlQDkgZVaOCDlto zM>*L{9wjctC8M)Crh6s6w^jqLgSr)=M{EEOPjK~aAQse00&XN7bHk10Rmvl%qJ&7e5cs+$eW62*k6Fx9Ue1eoER>YVSGUSn z8P25^%$J7Ntqj(wE+q#aCaWG7>4nvYFV-h7r5O&_TMd`9=rquyR+P+HpJGJcz0%%QqZT8I8c2q*N#lDB3wLRpF5yDC7VD%qnE_#%?Se1!$Bqp^qC51KMCW(`$ z1UpCr-L;$X44Rja8#l!Oqcm`Bp*7K|3OTlp2AdjFTbgyCZo@%#WFh|Sju$tL z1v;(cgmAqQUl7^h&QX)AQ?W3cTBZcsW`?WVJmo!)wZrY3qmFgkQIlJdnzm|MW6;~^ zwAv0*+mBij=a&t$JZbEuN)ad8&hJ}wxT8o@{yw(+eO~?xd-@9??|>KTK-BF(_UZtp zb)dC&V61dtJ$K-ccj5_k5(vea5Vz(^>WxTslCN}rcI0iXS-nEfOWK%EAY8iLJYL;=Y25;8S_2Cje;T_*$a_SEdc<{mzI*jZd1+2`17x4! zWk&$=2D30~a!vpV z;UacvLxpLBPUOSw&%+&QeKjk-xzD{tUL!%JgJtYUD%S9-CnNIYBU3`7u$j{QXpE8^ zuVIbY;X!Nowdc{Xk)elo0L7D05|zH$w6UYsF$wq4qwTRDt-}M>@CssY`z>SR&!bSk zv6Gc?*z-6+Q$MW-s9twSUuhsIZT!(|{7!Zp%Vz8r1MrM7L7+ED#DW1Y{EhVecvAR; zitgA3#^_!+Ic>+73>p+;sE8i3VR?}c%cErqeL7UDg;09h%wn3@8@=qd+aqrjC1S!} zw^yxn$nF`Qs*IGTZH!Z{+|;U=aWyUeVMeJeo$n=Cxh&DiYF4XlCfRdZw;4k>eY$4C z^7rnvzx_~g_>iMDd}!%kICdnoh#A_|sT`Tv`JyQe%vrhgSr0i_hPzFR&dWTx=k$l+ z`4*fxqxa}p7z6Rv6aLY|EwX*0a=m4(Xd~7$80n<=dZQX`b-H0wZZGK#VGEya7TBbh zdU56oy%)g37$xZorIpjRi~0dxBW#M}>((=9n3KsdGe^v`bm>K1ZS&C#OIfQ+a;NhZ zEEu|avmKQy?SR$F_ke0lLBe_c=+z!2@=21b35?T;Ht+FYZBxI{8%&31_RD57^_KcE z>rJfI4Bo9@3eTSF6=@+X1)kRRmeoDT&FXl}cgWSzv25JfOslo5BeAYlwNCFlt=ecV zr|9;MJx^e_EjOHwZoi-HmfLWNSW6mAQ5ap9Kdn1VU-5>?mCHPG(YDtgTW)Q-*LR+7 zIu1{9lrOQ5Z5;^LQ)A7(p006!Xb}3a4I9~bzqgUtI#j~E7{@Xrn-;_IF!w^f^iF^6 z=jo)@oY<0Zr3<+*ATX;qMwq}G;eUWPO`jbg*72Q zW^Kv>G*90V9i4kd-zCU(+7jv;12mj01DD*%R*apWkwIIXv(p|fs8b{v**nD=sM zvbBIF^Ww{w z)mQnmMAnPy@_*N-r-rs0XdnNfV_&_q``3?k*2lUa+CDP?yCA_nXT<(@vhwflYylj7 zj{Bv5_R9sA-64L(wOqv+iNf^x*cG4f4dTx$IG-z%j2occh0ypJ()!Kkzhk17OrZv+dnt-rRig z$+sPZM{j%e8FR}qay>y{59F~O%6b-neHD*=b2@gX_Iv%Z{X|E5&+Yei zPuZQz+R2CCx8KM2rLZ5mGIn)-t~A&_ww&)dEZ?21t#|#sWIkOpe$5;Bb4B^(Id<)_ z?#F#^`AJ{Y^B3&>UWJ#?^^K2FBbKAXRM^V{r?b(2mRi5U3bbxreRk|iZxw}Lo99dU zHn5tr>r1x8gTMFsaF^mNz3b~o=dUZi0054Nrny^4a$)1Z!ofX|l!0Gbiy_2KtEg#k z@$dna3{8N2VuHdK$|zz9)do=DL=VA4p1KS?byBUYn2w&%$yey5n60JKEJ|BPR!Wm) zfu}-pdN#t^9>tKMVwMZC)S(}#KiXST`JA7OF1yag>{-4l{IvTW_0d;1ZTDhuth+ss(gEB6 z$%bIE;Y~|%7L26}c|MX4isWay2uo$F2I7&6!Zi~l{<@pk8xB(`T6+%VE}1LSZ4rfD z!qHY?)6#>5po~RB0nEePWxY(rVuhliDHjmlinTVc^I1Zs1F_a9bJTj#Jg2$k#51z) z&nWY>)h*skI_=^7H93C)U9ht_%S7W%H6+{$!ilM};jNOYI1E;lHq#XZ{;3W+~Lu)=IGAsDzO}rWkdh0a%*regljxZ!U%> zR@nbR`Gm%0h5uL+QB#d0f__@{B|XFl@&e*bbm0i}#ibFJE$qe-pw2?T#b#96#**GB z6c3aEgl-xx6Evt=Vw52eI;mnxt;;gXOM?B`L)WNc_Pm%?W!z_|v;$uywpg%saqS+rUaEf3v8bJL!n`riEL|pDUDdQAg ztWMe#!Y!$yRD>9!eT$+x5S?m;Tn}Aleg?!+p4Hr1V_Zf4vu3w znhSRLE|^_6s?XZdD?ay#yaSuKY)-t_;*ja`Z4`(u0%NjZtib!TF4&8q3SP*VHrabn z6;wLoJ&Csb(+_v(gQ0@MPy>;Zl`@ps-;RaY(ctx|!(1|Hab_@XFF{gk*x3MF+fQi@YHSi0rlJ0@fm;}%>|rX~{9$FL8eu8jxBaMB#z#SA+xv|X)AUfGYpaJ5iXcvCPzGVAimxT}D<_MuaG7gooro{hq&_gfk z08uWbB&;y+Wj1mM(>|dj{(I2N4t5APVx}S;H}B)hc8IXFrh2!2@SR2) zfRJbwnxb!4R6cukLy@&47a9DO4;OoDFSB#Wa%Rj2Q=A@W8_n&DUJ99zLD@$HZ-6;m z>SduQ;VlPRrWY7f96<3+H7w|>5os#D1nuY9OoI`@T;%tLeDkZ}A$toMP8k2vV2>Du zo>1m|j+dDCgcyU7ZUlJ*nE)9f(N3h#*5WHJ*Yq^^2a>@@CU~j<_|93*kmivOxZ9LT zF2D#?qRkPuDAaMcp&V4ey%K5WLx5+ba#Wt`H}04_nZ1Z(WEP4bCN+^}38T>%yCVbs z#VKxWgCcRRPzb_q=w!ISHp*SizVH(bu3Zbw5&#K!k< zYBTDu3x9V8K=hwKO?q=?PiCSKk_c1GU|tmUo0eB%m{xA%=z_Si6b+R`9*Ln&)L`}I z4M~{OF3Y=^;nZ^K?2B)7-eg_1S;fv}X(E46b=d0FcMjrhpe=iin13Dv#U zm~;#9uOb&&n#b z`5)kGI5wJo99;aGcLy>W93sr6DM6Lzy8_%}<-|O|M*Q&qpb4ik~dLk}MTsP5RxO`X`4NsNSe*6p4jq_OeAf+&D57IB^7U%NIkempiuWi^B^v3K7V4q9I zPM4Mki=f$`iA?2A1U!>b3J18c&%!K2b`FPHc$RdcGEw*#zjlsSZ09wTt0XFsl1-Mf z($c|2`vY1R`H4I~69(W5o#7cL$k`rJ`t2wbbIkR&P;$$|dF#899RDq|bpiY^K@tU` z;HsQ;ZrzX4 zZLFCdz!f%}707ocmXz0aKqTKVW8}qOsZ6WCL~mIq(9c8SE@naQzdZ77{#}`@aFa-@ zQgWTHCZBd7b3{7eWh(lAdYJ6(`(U&sKT7TT!)xzrPM66R$Em2MCoVtl@TnUDKoyS) zw6;b_MQY*io1%=uN_%UrV{0tq7`3N*w-)=&+A7zgb)q;!G*-_kbEnS!#8Pw@MO!iG z9XpRRZLml8_=A1Fs`puh3g_9J`{{)0yJS3EZEX6>*jTs@t&{1d(9idJ?{K=~6!~bv zzw%oKip6%a+CkVrl6NDo;VngT{O-2tcGkzMlduZZ@P2l9|7^C)4F!^KoyabA9*H`A zo8Gx%gHN{wh|R>%bMHPr3wYJb4rUT;2TGA~=Zge4{@VtM4XpHSS!}5S@joagw6jIvrgIu+)b%K)0)B3+VwkVss5(_WSOiaw2q_Y1U zMuGg2c6e2QZ^ZBuu`)?Ba3a2LUPOHCxR%lek{d|sTeAX&z70p{q66zD;07C16cDGLb#J-^AztFPHnAZg#{Er*e~=$UoE*V z&u&HF_mCh9zJNHz0F{6MhelK(2~rw2hn=Kf)3m;edx9B;Y}D$wnD=fQ)oOBgnsmI{ zKB~XNs?ZN}50;~^E#TJ4b2SQ`nDMfDFZ*EOZHv{fX9qeumT&he6 zHzhg5tgV$5Yj*kuYU%X%nIY_SVGl?r&S4DFu?f=Wf*^2O4S#y%IuHcZR;EBWj?KmhJ`3iMVE zzoIoHwb4@I_&9|JHY8oBBk@!Gn?drou5?L(T4{b3$rMqKnz16=F|-dsk9-O8MX}F7 zFkk}lbBc3BkjZtBNevGY9XF*vJlt16B>#gRry;$$t79E~Jh5gB>48BzQfQSDepg)( z{a}1DPAoNQl&^FY*gb*KJ#sS9##1x8Ch>#dXQVzc`Yuy=*$s$wu+$V-K zien^3p91f_NJ!}2LF8}PVr0Kmvg%+`U{P!l&?leIXVVO*GMf+>lnQ5nBq5gA!;XNc z?!V+rpRMBPf|$fBW&D(5`=Ww=g=_e;USGH#_>Cla0GRNU4V`_6nUzj29}GRbgA?S9 z_N4Un2RBa-q{Jbj>Y(p&v1d|swB!`N+V=YB?Cqds+>}I4K}keeZS0hcO?Q}% z1OZBL6I@pDX91&g2Qt070szUszTSnB#0ZtSDF~w4Gj5R9x*^8|ryblXo_~vM?*XZ8 zf^I*3#Nx>8HP2+zHjkUcGPLm7x5&xUw6T^>v@nKeS%CbRiD;7+aCJ%}H1`xE<%p~G z1P7tp^wE*iv%xHZIe`zBsE?T$cLArAVA=z6&VL+WBVyqVqcZwGU$b3C!MyCIX>N!? z`9!YS*_QpBdA}ZU58@QzDc^gz0Z~LF;87FFQS!w;xe06AGNBmfQv;bgINfJ_E>W|; zL;M}3;{_XYhi-G7AVpLhh!eGdIT z`141aVHvp~?TPpjp#j@WhH`{s>}v^sd>|D%83d0p?kzyd25E{SdZ?Q4Sv`nyD8_EN zh%UKqBw6rj+PP?^eou#G1<2TlVb%AUx^-k_X#$91odtKMR_=`s<)1V_6t+{Mh?zYI zwpA7@kSldKs^YA>U8%cXMNXJnUW$+D7?1?B@(aFFUBDIOuBxJ`&Y zi1m(y#=ca_as}*t?vk&?p0v%iHp3XI6i9japP8SO>ILe1D!qRTSk2eF;=xrtnB?#xhwpLA->_2TQUuh-Yu(U_NY!4mu93Q z)@fZg(SlCs{lkguqmSk>0z$sL9p>9$xU~M~YOJ_&Ql~BI$D8aSRX1uO$ zld{>@YCeh<%?S)-|E|ok4B;B6_@}K?y(AmOSS`s|q=hWF)7Y~9qa#iPY5zy75z`;) zK-I@$`n=)1?O-lt#ZUW!+MUZ4J31QZ;UPZaiiOkFd3j|o?~15Pa;sE27?@Gz)atXT z+i<1*-Qp2NgFgx;1=oe-ir$+vq#ZSX9a6~9>9J($XcrGM<&%Xmp0qjl zHa|F(Od-}S79;p6HSvwK(@wxIDI@nWXhcH(fQDriqs5L7;a|w)GMJj2w?c3`iBtKzYIVA zlI@q#5pYgb812zjvmO9ZAPs2PY)RraA`^i{27u%-qq&1_X^3#joHXnjpH3@s)U%RQS(XkG36;$e7!{G!3QP@6we;^>m4GS{C^Hf6bKP?5{*GY` zegMaq)`gL$V1J+(`+x)3kp*stkL`z#ZKVPC$WhOPP)}CIj&#R%F<|2zX&;AYBp=0d z4aj9wbxWju5pIJVe8>QD6RGE(l^INbWOfVlazsGrNan!`;_S-qGkv?}TG3T8e}9a=}Th=ENVpfmGg8G;Op0Mo<|}rx;k~ z*wf#=r|=849#O-nV4@Zdp2|In)+hq{B^iy#>~`auBfs;kV1);KC2y)oFD}PprRSiBB86#V~^hz8TiV16ri70ZFE=^@q1bMbJ46An2 z<#&fk3S{!S)$pzs!n3|jqZ?f$EDKbY@vxMzgZofg(G^PJv51I`pWah*FDo-;i>PM{ zv!fdm-Wvc%AZOe2&t;&J&F$`>onYz@GtFsW_HniuO ztg_|6*`NP`n406~aW>i7HqgFoCcUhTyx$3-*umFdh0WV+LOGE5*d5WkIPZ9VRU?=}|W(pSD` zY~abSUhD3NoNeHI+4*7n{;MxLM(i4=3RPgFqA(hQ{18xN0+Akv9gmZ#%n3mVAd7+1 z-DB00XQGiwu+S{*t|XU4i(Vj!Tn<@X9C&|VWV1iavO0iyJZv*13OgDVUIm{KjxHNk z3IA-vI{CY1xN;8$v_QBa5h&kz_X;H`Q(fwgTO zrf>lrWj~vN0A{6+?7{Wc{8eMfYiE7$H&OIqn^$LN$YU#q%;$uxi^t64{bk2GpOElk zMbw<76uzrCrf%Npu@8>%GEUS?9Qy+AG@}X-X?=NvGA>v)PE*GwDqgmp15}&Z$|xaz z{5PLYMBmFq?zd-NzOE6=!6^9gcJZ^DzvBI15ogGYa~fK^m0>MIhTO)=}w z1T&K2&8Fgw*8>v$r7d8(I0TD*{dWa3Yhagcs5l)MBbSjv+Eza2j)>_EQYd%|q%|}W z69Y3PRIf%yF~r+l;r+;yvgN4mNny5eOrU7sL6mB^n?6stDKA8LQi0bb$&3V2x z`pYKd-g2DD8Nn$VVNal=^c5K>EiD5M^j8QBP?Qb;Z8-u0CMJAcJ$zM7J<=Nkw;rRD4WqlKubXYKyJBQ?Y<%MX<=U=q zY;OI>wS`rv2=N5)NT15E001=p0y4MK|1N`q1fTE1NN8j(r4^~9LeTW#0}rR^RMK%| zxM&z>@ey;_m4_vc)mb82JYI?enUmS$Xnx4^_y1qAt#nQPXzJ`#Qw?uGI-2`+eC<2V zf$yQXEN2XITM83cGC@EkFe46x^m`(`Gag7iqnd=$JCO4=u$qYNXNNq| z5BG4Au@<+hqt)StiuJz>g@r2B{)L#oS-y~G}Gj}a&8Fj`|q5fP^RKJptxat zyn2$PZcP)7vaa*$_j%49n!*h*2G4=PPjK0l zF3f*wr1tRs(KJo3-ll!1+uQyPc%<`aiJSWhpD?99TsE; zF-FFQGXyR|25+bbAkhrSBF2nEIq4L$xH~j}w5F8&Qf%ifD~YSg``HK(D)bMdc_&e( zHH1?;%&&<9kdY6NWjc(Tcj+%GTyZ%*ZOAZMTo4dHtt3@6*B_vzd_Q!xQp>_zE#{mQ z9b7__-bkT<9?k4XRP~RW3nE5P< z_$d=ROrRvqWd=?@i4Q-cnB_)BN~LaohYGQ+)_EU}yIEo;cJ-e5z_OSk6O}d?M!e%Y zK1NuU^TWu4rJh8?tgByD!{%mohlFmx_?Eu2Sd}Hs6RG*RSwlQ}qK!%1#3dtNZc=oC zEBV5=`$o3)YEWg)vNVoZ%``-n#*E1T>idW&B(ual@Kch(XNumZk@mWf3N(^cbl`U; z<#Y<5F+M#tv#l^s1&M{rZVg?i^XKE2MD`_0cEFQGe-rpditD5ZMo#QNq_j6cmCuC7 zmzto*4amf@Ht0mQ493|AHTc3z55`i)M*HrtabhXXE)Amyb3yi8ACIMpSXhX1y}#14 z)fZubNI;}}TNaYAq%hq7K#b;9v;%tA`yRnvif1PEhyYh96ARnchX~j{?p8 z!C8@!yUBJt!30vdwH2p%@`rR7B_Vx+(X!v;(`H^;&m01)wJ5+rMM!lhOxi%$1G z;Ij{PMBwzMU;HF>m=<%0Pr~Hl-3Y_)j*GcT6HWe*66R)Rlw(K*bmBV`}bl~42c=DSc*Uf2`}9gdU7J$ zh$wBm*L&h{nL1H7XY!rTxhYa8xHF`G}0{fe5F#X&IW@Fhp2LiyZyuqDgs z|H1k?hhp|%i+N}gVmkw*{ltLJ+N_Ms{wWbuhsn}3aXNxQuQ@l<=%9nanNfM4o7TNk_tw9=_##t3X|e8{vtA|MGklJaO6hEaR__g1Wn`^G)*+ zw$A6!)r~I=jlIHFu1TJH9cZr2`+?;ygC#3_<-|=>H)kHbo@@6I;_CZ0X~m!XGoJ=8 zNuG|^`L=%OpS_WTd(tbwi^Hpa9)z9e5%!LxPjeMR4Xu#2ZKldF!<)$YcAR#0x6^m} z*yudv7+5Es{3BaE^?ZNX^9Oy7LzlmQvuc3H$gOjGl|4>lWM348Y=SWHIAj;Y?Aw0I#82DnoIzO& z$7IsPCT`0wgbgDfT~mf#(mB1iSJo6hFIMS#b9j|m9UbNiw2mf}#~rp>YD9UoSKB%T z*tMsdJ(3U4YNH%|?$_2oTT8RsBtlBS!EB$qPj7^=Sho;SxK_m|`i` zs4-XbetsNAulMn2cYVKa`RuE2{VVLgqH*yd%w@S$ceHj!t2XI3qNeX-0lS&2L$<52 zB#ptXnJ*5BpD%}xPQzEs5GPM3HDOas>F>XABn-!UjDIIede35F?fTt*m+hj(qCYT@ zMz)ld&|3mH;%VZa2lD}vF-Y!px=qczcl-dp+a zIOx+lN|N|&Y|-joBw7Od>=s;pcFY-Y&{>U1XdL6kG>vSj57Q2cJamq%Nd_M;*d8_7 z9(_0C*pIvz&?Kslq)?AWTm-N2VL2zey7EP;@kH1)MkqE$As>RoUCjTQ#&|o05^F_~ z!5AzXzel{Mw~(j@nG}YFnFjdpnT$0W`~_N{(NjfF>wsyT?IZHkqei~W)k|5Z97`Znm3MZ6o2(LdUR9jQ2thTmL4jw#5$Q;}nY zLrgN%6FtE9!uF#Cc1}>Xxt^!xjXRXZA!t@XokB{7$%Ep;kjDDj< z&W|SW)di~c^O@MtEJUd^IjY}mI9>n(?#-esYHe?x6#G$L2A`xqjT+gkGT!76_ha`z zD-CXJ9y#ns31+6~uWCMZJ7Nb(?oBhCi#5w#2Sud);5zKStn>}#JeiK+~$vx(( zH+xDwdJ6FQ^1J8hleyEO84%y+nRs|_slZ0Q0w zw0xT(YZBKub2J-wvO+)Nyi}fSQohg;lMuxPGg|s!PIE9Ny*=6kUffX>mqwAVU(tuk zqSDHu4>;s$5X=lRz#jpcWHN}KDwxHgc)_4RGBB9gEdhuW9MM>aoe=X=DgfCf2o6+I z<6+h=lh`GLnYUEbtyDUTQ=Da4ye8r=ei$U+j%D}=i5&#nXqEinGp`~m1(BrHH3zL| z$4D{+$`tW&Uo5LmOK69hwpv zcDZL;>|vH)WEVFOWmH%Bnwa<#sj^Yp@>$bzIUymB&oG}q6$PeKdB#(9;!!^Iwy`Eq zTxL*BGh99_Q%pNteR@>XyHw5kgvR7qJ#MY<{s zWd33rMkENXTd37}0Evav3`48aWvbnN6w{?PFdsK~JvDGFH&9xY`n_w+D=z00Yy^8Y zhW==z32S@=#&!3`yFS!wd4_9R)#El*Bp=twhxtAi_%=(FRcV3`O)Wp|#oG_Z|9CL` zL>v6wDl*C?y)h9Iq*Zs>XokWcotPRa{t#1#ZgnVC1KXErjJ0YEL9ZDKE9bRpWIt|= z9&Y{pgyH(5?Gt+2f=(kAPwd}R{UV(@h6AHOYDXT5#woqF?ATYbzGAqaXvJ6zBBXlrx#o*$l2$D zm-!95PCsXm-An!JGuTzy(&7B@*J-ioFEpy{pv#NY^gg5nwA`Vx(yaKl;(v}G5%2sE z-bzm1HF(_UYSl)(g2A2I2C-_TDQ)HP>@gdJRfv=KOD5OJK9|}acYG$V7}@xPgokl# z!2+e@c(e$3Dvk|wAK=7j4z@@Ne@Fx$cJ(&Kg^|@B1P+8V+i*4|$_Ylqd-X=T^(*XE zI1coBSamKfH+Vj^QhIeUwsiVG_4*1{7lwDP3^$kyHCd%bg?ZI$rVZm3B_pNvC#NR0 zhDX5j{)sts#zTY#uk-{~mM@0BOHHVChalgk_ViZCt@uq!*+kT(xE-b>G^Khs zrlb^(mRO7~p^f4T+BR8830c*IrdE6Cj0=`jQ>Qk}>(qP>8^4zw4oj^uldVB~Ujqxb zB}Pv>)=k~P&jUf(Paq|2-Wg>)+M_J`EXjbp+;~ky*K74&eMTleR}K$KhDzdmi0tuf33}4MVT{y@2G_-veZA~V3K3; zem+iPhCj*qpQq~AB{wF4T*uYtL%9t zvu!sEi4oR@mVVFEc}c5_l86f(`-|C_i`h>J&Jp(74S|jVOQmg6nV2qR@0ZKpFDfK; zYcno4>WPPznKrF1BV8{|A1=eXSon>+DP{#$1|qn9y)gz?S2V;5V+I$;gjdtSxk8ew z3pU=hHuIC5i6azV*XYZO!fU8qQ*h1Qw)@?_l4~a{t8YG3vhUvChMazlZ4wK22kPnc;
NJBr8l*+>3!pZ>`f<1VQh5z!dWX991Pqv^fncj8Lo^}`!@J!yPhY&c=(sd8HIpRb z>i+~18tvtVj=h{+=4IfsuIpCz>!>+ymbrrWnCiyGVAuNV;#Na)KG}b2zr$WY-t1k* zT!rbL?%HKo&}eMl4()Df?9{esiCS;TsFZcPXVQ+z(U9Y}UG4^?S7U3o5lzMF#<{3F zz+%g5fp%a~mZ*{J?-BkhXKu!*m^ra~Eay?nbIBm^8rqJO1Ki{e^81DLLS5~{AREI8B_a865wN>F+B94`7c-U zfA*Ua|A6oU05CN;6@ZwixX9S(_y`#(IZ0V*d5M{+xyjk-`KdTC(9j@YdMY4FdRhP= z5ODg!Aj>dYTT46p@?vs0_3OK9GCVkF0*aihyv(f0Fj4|@xcd^IMWeO#qLr2PvVpb1 z#Z|`D#RVi%3?RZ#2v98uFgy5BvJNCa0x}p7GFWShpc3`~m|y@ffV@Qu1E^c@j$gHA z6f0W1{)jQ7#*K?ql|p68BP&<1Ox==2YnLu+)DA70GRuU)brU(-yopm2Om*<)F-Vbu zMv7}$Xk^i%C7e=lTzI++@GhRAcktvLlgFgT4+a5biby1=9g~2AUI^@`Xdyy)3X46> z2{*3XxpZxc1et2oM**!~#j+-F!97MkxbEpB<^@3;)g;GNhDnjp7NkyCgB1Y zg|)E+B`rE4;!BZM!sQN2)&NDBiQK(F!V5ytu*Fc=q~J{!OaTxhIc1b%&RZP4L*SKm z-ifCtM~0-=NJ_{c4B2DjJesF-E;#^IN!ur z&N)A9l*R`&DT->Uss^xUUaOdL+$qX2`6NqK%DHN;%-p)^7FleOVhWQv#~uD zrjRU9zak}GH*K01+PIt;%K;^q4NP#s1*c(cBxwji2E&z1VFVgWP0a5GXe9iS7h;Iv zg%pxVG0r$1Gh&7rXOw(0$|akuvKdU23v(!a;?=FJ;0{`=SuyYY2~6f~dK9o)1W~3? zB|5hqypjS%ri#gS#u+#1mf81`Pam6aIE)*8poYvBe~9 zX?H1Z0W9S-yr`y9qUDeU7l}J!?9wD)t?;wnwNZ7iM&4_v6pb>Gz zV=yuN7-M+BubgX-vw_=@paFLyXViV86ii65g!R~4AI0@&EUqo!uL}O>tT%?}R5=P0Pk*I7yAc?1BY&dtxF|=|CiMX=xmU zr7R7mMO^A`pZnY;BRmKRG-wQtj2L0afQJU+B{T~DXxJVd<(4-lTu-9hI~_Hxv`q39 zQbM_a=8rB4QYuYhTI9&)QsRe&^1J{GkmE)rIYYkz9_3!ta-tKLScaa|B8{o*4wsD8 z9m?Et5n{Z|P%oiIekv7TU+CRZA|Zwlmhps;U;+>lLM)XV-u!eEx-Qt2tUoBB91^X!&(9f zVT&DL{~AZY0u~Kn8^a`6o2o(3(D`GYwl4CEjS*}pbMPGG>r zi^Lel9l+pCl0P}*C`)+xI#lOC3wqGMx$}|58YKyx9K1gm}XYG%Z`F|$5Utu-?1 zTHiXT!a&4^n^dlBKDgu2ZgiFJ$n+ube(yCD(le2=@{x2r)eZjF|@Q^KG9S+BI)E%>iEWeGh!-{Qh^#18#AO)7;?WPWsPv zj`VvQ9p^HqcfUU#^qt2%*GB&~(Pf@>a`_s~PP#NNICLQ|3t|`(zxd2Q?sm7&yyQg3 zI>Cc}cazgy;8CAD-1{!{tZUojSob%;Pmc7AuN>ug2fMBf4)3Q|T<%Ms{MNzVc)KsY z>MK9G$}4~Ox6i%j`G)+^3vceyU!CeEN4?LlEq7|mJ5{4bG|mzoO(s_pQ4>FU+(qyA z%f~+F!VmlKHGl4?D?RL^Cw}CK-*e2vyy;r6e&c_RZjWQX>%iZB@-q*5>T}-J(06{} z#eZ{^>z(}S55D#OlP-JA8=vY2AD>spS6f3OnI*k26mJ)oaf+vO(?@y#wtkiOdeJ9( zT<3eM2Ym1cbUr74E;n@{cX&-#dhgbE+XjJ_ka`4Yc%J8YomYG)H-LmEdE-Zd0(f!> z7Ggr7EbM2Hb%mt$oo zE=-scNhpO2LWNZ*Y6!;8L)(p$HiY&(wte8x0 z$Y0R33>CPGJokC9D2m8Hiy1+R!nkp`c7#WGg|C=?@#c)1P>e`;jP8bS$!LsbQ8THYk)xjU%WG%UB8RR*t}kjIH>KrFf3PIF7#PfzPN3%t(ywSdIBOfyrQx zexnN82#^X_KF@TAjL47ew}W4IgGG0YR=0%lmx&3vcupsKGAM#9D1p!Cc`T@ks@H%! zn2eeDff8wpmnU$^XM-3hbuIXjBDirJ>5-fFa^%K=F$sTl$C59Zk*cSPF?f=&=#d2% zlm0&GbT$WhGe}LM-~da>luhXX-MCSQR**ZU3&S>S(!_oysdz5Ad^sp|jCXiJ$&g!T zf+snE)0c88c!D=~gJtQHCV7!yDSd7!d~}I#@V1p}>4MEDi(|=>c}b3YnQdc9mKkZ5 z!zY*&NSN>EfQH9?>Iar>>6Izhk1?Z^PU)0TX)}@-6H1mLOr|5931yl%e>FIn7WtSx zX_QxomVfz^1lXD{n1B!Yf)@Fejt85kc$=&FbaJViys2~Ex0kPpo6%>0vALUr*_f$G zoWi-4Y5AO5cbu#jn84X?$f=lHb(xsSl$vQ0dBy-*W*TT`m7Jz(&WL(U=bY4;{(}zr za`C5?>M4UF2cOJ2evyfgODL1%hFNp`qEY;5*sYt|fr_?8iga~!&JkNKPM zh@HO(g6s*SYDtR%sEq2Ef?3&oY>9pN2&DK}qx<-yDX5=zIgB$ZoLc#!YU!i9hM(v+ zZ4X*~SL%XGilnzV03q6)BWh&e$x+OqWPa9YmH3h%_U?*aoq%VU zaLSgII;o9mejB-g6}m_u%AMXBRvndQP?BSdMht06n)1hVIm&V_dZ9Q-gMpcW8LF!j zYMOwFtGB6;r?{ZFS*syOo4HD=%Brj~I;&Ypt15Yk3dwatxude#ke1r34{56_*>w&X zZWb7VFG`WS3YQ^es+ftYm1ao7;0v0jAzKz{`WcUpn2L{xC+V7*V!D|?SZZK+YG?Ol z^Gc)+TA70wjrb}g`r4H1`fD8(Y<*UqDta38T9R_Au%noN=W^hW(^l?Z5AC| zW^5aavMHOdUkauo`mu!bu#1=>7m{{-wswxDvN@}>9@4Q(iK_nlwTQSE5KmDhli&eI ziwH;S0T!XOO4|uYo3xJrwG=V6nXt5tP_>JYwOWg`P8$GT%LrTR2w4lZ7NHyEcCb79 zp)3og4y&p`+kgJYdz)~zUz-tiYqy+$w~(;6%+R->@VAK&xPnW#g*&#Du(x8%x12DP zl#sS+TdHguqCZQJ|2l+#8?|?<2!m_1l)$;j@VT16xuILPrMtL@Yr3JUwTx?x`UtsF z*0V0lOx{?cDj|f+aJ6^~wYgimOWV6&>$F{Kx`qq9T#L27o3y%%ym`C3#Y?urTfBnX zyj$zF&>Ov*yS&LOwPb6!%DcIF8wtysz1qvW<@>u)tNys?_@+gfmPq-!*eJQD%C9h_ zh+n8P%22kMo4e%8yVnc7y$iO@>%57pz546B`&+pE3%=6pyan991Ps1iOT5ghz<-Ot z-J8G&9K4bsz7c%D`rEx1%(>ypzI_Ru?^}p1E4vyMAxDOW0E@p148qKtz!^Nlb_>A* zyuia7!8LrtJnX28^{*i^E5(!=$^!M@+*+jKnhRqs~d6(}}{mT{yQtBhP!p#z!W^iQOv_Ye8+JN$4%VH zR4m7$tjC{R%65FZ#_PXxT*|Br%GWEzefzoLs*}anrHqWOUuu7OvBLTHwjQ+$mF&kK zjJ`O`$I%vw3&Ik7%zXUJ$BfJ~49&&7#G{IONIjz(FJI&KQ?bAOE)IlxOLrv60ZPYxy(o(pctFYAb z3n<^HXcThNHI%35>@GASQ*xB?beAf z)@8lbhvp=n`I(0zn(Fk{d(GFT8oxgap5n=7Qjo#_4-s{cY?G4=Bz1gPl5dlfx09hRMjo{0+aV6+>^^45(AmQr04icQc>6br;$u96Q zFY_}`>3?$R{s&L&5`X{_KmePb?IZu&vF_*HPVqn=+$b*r0)X)WK<-SR0Rh1Az+LGA z0Pi}Q@VQ&F>4)25R?=cVaGq3h*zwAsc=7Mh*duAOR0h_Abxw zY0vhX&-rNn>}swgnBMc7p7T3D0h^BP*-qTCe)XEZ_k5q{6X5s0{p(HN^igl<5}^CK zAMU}8_*T#O0ATeXAMcP4<7VI8lP>`k!2HZF?3Zus0U#^2k859bX3 z=@2mf=exiAzYXz<(B0jK4ZwkRb{8V4|TW|clp5>Dd z2muy@gbx4$hyo3Xhy#p|kdcy;l$Dm3my3yxn4O-VprN9pq@|{(sHv)}tfHETuZR$g zoRS0x0uu#&X9+ZFcq4-tonu>!TN00GAO7qFngg9sBUT*$DYr&x>PC5lIo5rK8M z5bfGUAOeAp#60~9MzUmtW(24SSjSQTH(90#SU_M-z`1gi+9i6olHWWC+6WQS$Ef~a zMTbZq4NS_ksne%Wqe_hg5vIghM-i=?U_loIW)Tof_&6+NCzEJTLP%LDZLn^qEC{lY z5|_G4IuY@dsL4@;uhN*611FEx)TB!fD_+dFv17$m8Nu~OX{-bZVm%_VEDD-uXq`Sg zQ}w{Y18)#;Udk(AuTRRIj6P17c((1^xO3~a6j@T%-G^DbF8rJ7qvF6_8BWf;x%1}= zd$WVCSU9}b$dw+aUaB_t@8H9WFHC;=_@>r-5^uo1z5Dm)Q3FIM;e-@cXyJtzW~kwY9Cqm8hZN4E*SU4&ooC{S zD5j|5iqyG7q9QEDDC3MY)@UOuE~=*ph&=Y_NG7S|l1w(~0+ zo_zM{=bwNED(Iku7Ha6Bh$gD&qKr1`=%bMOS`m}aW!rkr-_>8GHED(a}D cmTKy$sHUpws;su^>Z`EED(kGYni>cIJO8`nHUIzs diff --git a/docs/manual/misc/custom_errordocs.html b/docs/manual/misc/custom_errordocs.html deleted file mode 100644 index 6a426a76f2..0000000000 --- a/docs/manual/misc/custom_errordocs.html +++ /dev/null @@ -1,489 +0,0 @@ - - - - - - - International Customized Server Error Messages - - - - - - -
Using XSSI and ErrorDocument to - configure customized international server error responses
- -
Index
- -
-
Introduction
- -
Creating an ErrorDocument - directory
- -
Naming the individual error document - files
- -
The common header and footer - files
- -
Creating ErrorDocuments in - different languages
- -
The fallback language
- -
Customizing Proxy Error - Messages
- -
HTML listing of the discussed - example
-
-
- -
Introduction
- This document describes an easy way to provide your apache WWW - server with a set of customized error messages which take - advantage of Content - Negotiation and eXtended - Server Side Includes (XSSI) to return error messages - generated by the server in the client's native language.
-
- - -
By using XSSI, all customized messages - can share a homogenous and consistent style and layout, and - maintenance work (changing images, changing links) is kept to a - minimum because all layout information can be kept in a single - file.
- Error documents can be shared across different servers, or - even hosts, because all varying information is inserted at the - time the error document is returned on behalf of a failed - request.
- -
Content Negotiation then selects the appropriate language - version of a particular error message text, honoring the - language preferences passed in the client's request. (Users - usually select their favorite languages in the preferences - options menu of today's browsers). When an error document in - the client's primary language version is unavailable, the - secondary languages are tried or a default (fallback) version - is used.
- -
You have full flexibility in designing your error documents - to your personal taste (or your company's conventions). For - demonstration purposes, we present a simple generic error - document scheme. For this hypothetic server, we assume that all - error messages...
- -
-
possibly are served by different virtual hosts (different - host name, different IP address, or different port) on the - server machine,
- -
show a predefined company logo in the right top of the - message (selectable by virtual host),
- -
print the error title first, followed by an explanatory - text and (depending on the error context) help on how to - resolve the error,
- -
have some kind of standardized background image,
- -
display an apache logo and a feedback email address at - the bottom of the error message.
-
-
-
- - -
An example of a "document not found" message for a german - client might look like this:
-
- All links in the document as well as links to the server's - administrator mail address, and even the name and port of the - serving virtual host are inserted in the error document at - "run-time", i.e., when the error actually occurs.
- -
Creating an - ErrorDocument directory
- For this concept to work as easily as possible, we must take - advantage of as much server support as we can get: - -
-
By defining the MultiViews option, we - enable the language selection of the most appropriate - language alternative (content negotiation).
- -
By setting the LanguagePriority - directive we define a set of default fallback languages in - the situation where the client's browser did not express any - preference at all.
- -
By enabling Server Side - Includes (and disallowing execution of cgi scripts for - security reasons), we allow the server to include building - blocks of the error message, and to substitute the value of - certain environment variables into the generated document - (dynamic HTML) or even to conditionally include or omit parts - of the text.
- -
The AddHandler and AddType directives - are useful for automatically XSSI-expanding all files with a - .shtml suffix to text/html.
- -
By using the Alias directive, we - keep the error document directory outside of the document - tree because it can be regarded more as a server part than - part of the document tree.
- -
The <Directory>-Block - restricts these "special" settings to the error document - directory and avoids an impact on any of the settings for the - regular document tree.
- -
For each of the error codes to be handled (see RFC2068 - for an exact description of each error code, or look at - src/main/http_protocol.c if you wish to see - apache's standard messages), an ErrorDocument in - the aliased /errordocs directory is defined. - Note that we only define the basename of the document here - because the MultiViews option will select the best candidate - based on the language suffixes and the client's preferences. - Any error situation with an error code not handled - by a custom document will be dealt with by the server in the - standard way (i.e., a plain error message in - english).
- -
Finally, the AllowOverride - directive tells apache that it is not necessary to look for a - .htaccess file in the /errordocs directory: a minor speed - optimization.
-
- The resulting httpd.conf configuration would then - look similar to this: (Note that you can define your own - error messages using this method for only part of the document - tree, e.g., a /~user/ subtree. In this case, the configuration - could as well be put into the .htaccess file at the root of the - subtree, and the <Directory> and </Directory> - directives -but not the contained directives- must be - omitted.) -
- LanguagePriority en fr de - Alias /errordocs /usr/local/apache/errordocs - <Directory /usr/local/apache/errordocs> - AllowOverride none - Options MultiViews IncludesNoExec FollowSymLinks - AddType text/html .shtml - <FilesMatch "\.shtml[.$]"> - SetOutputFilter INCLUDES - </FilesMatch> - </Directory> - # "400 Bad Request", - ErrorDocument 400 /errordocs/400 - # "401 Authorization Required", - ErrorDocument 401 /errordocs/401 - # "403 Forbidden", - ErrorDocument 403 /errordocs/403 - # "404 Not Found", - ErrorDocument 404 /errordocs/404 - # "500 Internal Server Error", - ErrorDocument 500 /errordocs/500 -
- The directory for the error messages (here: - /usr/local/apache/errordocs/) must then be created - with the appropriate permissions (readable and executable by - the server uid or gid, only writable for the administrator). - -
Naming the individual - error document files
- By defining the MultiViews option, the server was - told to automatically scan the directory for matching variants - (looking at language and content type suffixes) when a - requested document was not found. In the configuration, we - defined the names for the error documents to be just their - error number (without any suffix). - -
The names of the individual error documents are now - determined like this (I'm using 403 as an example, think of it - as a placeholder for any of the configured error - documents):
- -
-
No file errordocs/403 should exist. Otherwise, it would - be found and served (with the DefaultType, usually - text/plain), all negotiation would be bypassed.
- -
For each language for which we have an internationalized - version (note that this need not be the same set of languages - for each error code - you can get by with a single language - version until you actually have translated - versions), a document - errordocs/403.shtml.lang is created and - filled with the error text in that language (see below).
- -
One fallback document called - errordocs/403.shtml is created, usually by - creating a symlink to the default language variant (see below).
-
- -
The common header and - footer files
- By putting as much layout information in two special "include - files", the error documents can be reduced to a bare minimum. - -
One of these layout files defines the HTML document header - and a configurable list of paths to the icons to be shown in - the resulting error document. These paths are exported as a set - of XSSI environment variables and are later evaluated by the - "footer" special file. The title of the current error (which is - put into the TITLE tag and an H1 header) is simply passed in - from the main error document in a variable called - title.
- By changing this file, the layout of all generated - error messages can be changed in a second. (By - exploiting the features of XSSI, you can easily define - different layouts based on the current virtual host, or even - based on the client's domain name).
- -
The second layout file describes the footer to be displayed - at the bottom of every error message. In this example, it shows - an apache logo, the current server time, the server version - string and adds a mail reference to the site's webmaster.
- -
For simplicity, the header file is simply called - head.shtml because it contains server-parsed - content but no language specific information. The footer file - exists once for each language translation, plus a symlink for - the default language.
- -
Example: for English, French and German - versions (default english)
- foot.shtml.en,
- foot.shtml.fr,
- foot.shtml.de,
- foot.shtml symlink to - foot.shtml.en
- -
Both files are included into the error document by using the - directives  - and  - respectively: the rest of the magic occurs in mod_negotiation - and in mod_include.
- -
See the listings below to see an - actual HTML implementation of the discussed example.
- -
Creating - ErrorDocuments in different languages
- After all this preparation work, little remains to be said - about the actual documents. They all share a simple common - structure: -
- - - explanatory error text - -
- In the listings section, you can see an - example of a [400 Bad Request] error document. Documents as - simple as that certainly cause no problems to translate or - expand. - -
The fallback - language
- Do we need a special handling for languages other than those we - have translations for? We did set the LanguagePriority, didn't - we?! - -
Well, the LanguagePriority directive is for the case where - the client does not express any language priority at all. But - what happens in the situation where the client wants one of the - languages we do not have, and none of those we do have?
- -
Without doing anything, the Apache server will usually - return a [406 no acceptable variant] error, listing the choices - from which the client may select. But we're in an error message - already, and important error information might get lost when - the client had to choose a language representation first.
- -
So, in this situation it appears to be easier to define a - fallback language (by copying or linking, e.g., the - english version to a language-less version). Because the - negotiation algorithm prefers "more specialized" variants over - "more generic" variants, these generic alternatives will only - be chosen when the normal negotiation did not succeed.
- -
A simple shell script to do it (execute within the - errordocs/ dir):
-
- for f in *.shtml.en - do - ln -s $f `basename $f .en` - done -
- -
Customizing Proxy Error - Messages
- -
As of Apache-1.3, it is possible to use the - ErrorDocument mechanism for proxy error messages - as well (previous versions always returned fixed predefined - error messages).
- -
Most proxy errors return an error code of [500 Internal - Server Error]. To find out whether a particular error document - was invoked on behalf of a proxy error or because of some other - server error, and what the reason for the failure was, you can - check the contents of the new ERROR_NOTES CGI - environment variable: if invoked for a proxy error, this - variable will contain the actual proxy error message text in - HTML form.
- -
The following excerpt demonstrates how to exploit the - ERROR_NOTES variable within an error document:
-
-  - <p> - The server encountered an unexpected condition - which prevented it from fulfilling the request. - </p> - <p> - <A HREF="mailto:" - SUBJECT="Error message []  for "> - Please forward this error screen to 's - WebMaster</A>; it includes useful debugging information about - the Request which caused the error. - <pre></pre> - </p> -  -  -  -
- -
HTML listing of the - discussed example
- So, to summarize our example, here's the complete listing of - the 400.shtml.en document. You will notice that it - contains almost nothing but the error text (with conditional - additions). Starting with this example, you will find it easy - to add more error documents, or to translate the error - documents to different languages. -
-
-<P> - Your browser sent a request that this server could not understand: - <BLOCKQUOTE> - <STRONG></STRONG> - </BLOCKQUOTE> - The request could not be understood by the server due to malformed - syntax. The client should not repeat the request without - modifications. - </P> - <P> -  - Please inform the owner of - <A HREF="">the referring page</A> about - the malformed link. -  - Please check your request for typing errors and retry. -  - </P> - -
-
- Here is the complete head.shtml file (the funny - line breaks avoid empty lines in the document after XSSI - processing). Note the configuration section at top. That's - where you configure the images and logos as well as the apache - documentation directory. Look how this file displays two - different logos depending on the content of the virtual host - name ($SERVER_NAME), and that an animated apache logo is shown - if the browser appears to support it (the latter requires - server configuration lines of the form
- BrowserMatch "^Mozilla/[2-4]" anigif
- for browser types which support animated GIFs). -
-
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<HTML> - <HEAD> - <TITLE> - []  - </TITLE> - </HEAD> - <BODY BGCOLOR="white" BACKGROUND=""><UL> - <H1 ALIGN="center"> - []  - <IMG SRC="" - ALT="" ALIGN=right> - </H1> - <HR> - <DIV> -
-
- and this is the foot.shtml.en file: -
-
- </DIV> - <HR> - <DIV ALIGN="right"><SMALL><SUP>Local Server time: -  - </SUP></SMALL></DIV> - <DIV ALIGN="center"> - <A HREF=""> - <IMG SRC="" BORDER=0 ALIGN="bottom" - ALT="Powered by "></A><BR> - <SMALL><SUP></SUP></SMALL> - </DIV> - <ADDRESS>If the indicated error looks like a misconfiguration, please inform - <A HREF="mailto:" - SUBJECT="Feedback about Error message [] , req="> - 's WebMaster</A>. - </ADDRESS> - </UL></BODY> -</HTML> -
-
- -
More welcome!
- If you have tips to contribute, send mail to martin@apache.org - - - - diff --git a/docs/manual/misc/descriptors.html b/docs/manual/misc/descriptors.html deleted file mode 100644 index 75aaedf874..0000000000 --- a/docs/manual/misc/descriptors.html +++ /dev/null @@ -1,196 +0,0 @@ - - - - - - - Descriptors and Apache - - - - - - -
Descriptors and Apache
- -
A descriptor, also commonly called a file - handle is an object that a program uses to read or write - an open file, or open network socket, or a variety of other - devices. It is represented by an integer, and you may be - familiar with stdin, stdout, and - stderr which are descriptors 0, 1, and 2 - respectively. Apache needs a descriptor for each log file, plus - one for each network socket that it listens on, plus a handful - of others. Libraries that Apache uses may also require - descriptors. Normal programs don't open up many descriptors at - all, and so there are some latent problems that you may - experience should you start running Apache with many - descriptors (i.e., with many virtual hosts).
- -
The operating system enforces a limit on the number of - descriptors that a program can have open at a time. There are - typically three limits involved here. One is a kernel - limitation, depending on your operating system you will either - be able to tune the number of descriptors available to higher - numbers (this is frequently called FD_SETSIZE). Or you - may be stuck with a (relatively) low amount. The second limit - is called the hard resource limit, and it is sometimes - set by root in an obscure operating system file, but frequently - is the same as the kernel limit. The third limit is called the - soft resource limit. The soft limit is always less - than or equal to the hard limit. For example, the hard limit - may be 1024, but the soft limit only 64. Any user can raise - their soft limit up to the hard limit. Root can raise the hard - limit up to the system maximum limit. The soft limit is the - actual limit that is used when enforcing the maximum number of - files a process can have open.
- -
To summarize:
- - -
- #open files <= soft limit <= hard limit <= kernel limit -
- - -
You control the hard and soft limits using the - limit (csh) or ulimit (sh) - directives. See the respective man pages for more information. - For example you can probably use ulimit -n - unlimited to raise your soft limit up to the hard limit. - You should include this command in a shell script which starts - your webserver.
- -
Unfortunately, it's not always this simple. As mentioned - above, you will probably run into some system limitations that - will need to be worked around somehow. Work was done in version - 1.2.1 to improve the situation somewhat. Here is a partial list - of systems and workarounds (assuming you are using 1.2.1 or - later):
- -
-
BSDI 2.0
- -
Under BSDI 2.0 you can build Apache to support more - descriptors by adding -DFD_SETSIZE=nnn to - EXTRA_CFLAGS (where nnn is the number of - descriptors you wish to support, keep it less than the hard - limit). But it will run into trouble if more than - approximately 240 Listen directives are used. This may be - cured by rebuilding your kernel with a higher - FD_SETSIZE.
- -
FreeBSD 2.2, BSDI 2.1+
- -
Similar to the BSDI 2.0 case, you should define - FD_SETSIZE and rebuild. But the extra Listen - limitation doesn't exist.
- -
Linux
- -
By default Linux has a kernel maximum of 256 open - descriptors per process. There are several patches available - for the 2.0.x series which raise this to 1024 and beyond, and - you can find them in the "unofficial patches" section of the Linux Information HQ. - None of these patches are perfect, and an entirely different - approach is likely to be taken during the 2.1.x development. - Applying these patches will raise the FD_SETSIZE used to - compile all programs, and unless you rebuild all your - libraries you should avoid running any other program with a - soft descriptor limit above 256. As of this writing the - patches available for increasing the number of descriptors do - not take this into account. On a dedicated webserver you - probably won't run into trouble.
- -
Solaris through 2.5.1
- -
Solaris has a kernel hard limit of 1024 (may be lower in - earlier versions). But it has a limitation that files using - the stdio library cannot have a descriptor above 255. Apache - uses the stdio library for the ErrorLog directive. When you - have more than approximately 110 virtual hosts (with an error - log and an access log each) you will need to build Apache - with -DHIGH_SLACK_LINE=256 added to - EXTRA_CFLAGS. You will be limited to - approximately 240 error logs if you do this.
- -
AIX
- -
AIX version 3.2?? appears to have a hard limit of 128 - descriptors. End of story. Version 4.1.5 has a hard limit of - 2000.
- -
SCO OpenServer
- -
Edit the /etc/conf/cf.d/stune file or use - /etc/conf/cf.d/configure choice 7 (User and - Group configuration) and modify the NOFILES - kernel parameter to a suitably higher value. SCO recommends a - number between 60 and 11000, the default is 110. Relink and - reboot, and the new number of descriptors will be - available.
- -
Compaq Tru64 UNIX/Digital UNIX/OSF
- -
-
-
Raise open_max_soft and - open_max_hard to 4096 in the proc subsystem. - Do a man on sysconfig, sysconfigdb, and - sysconfigtab.
- -
Raise max-vnodes to a large number which - is greater than the number of apache processes * 4096 - (Setting it to 250,000 should be good for most people). - Do a man on sysconfig, sysconfigdb, and - sysconfigtab.
- -
If you are using Tru64 5.0, 5.0A, or 5.1, define - NO_SLACK to work around a bug in the OS. - CFLAGS="-DNO_SLACK" ./configure
-
-
- -
Others
- -
If you have details on another operating system, please - submit it through our Bug Report - Page.
-
- -
In addition to the problems described above there are - problems with many libraries that Apache uses. The most common - example is the bind DNS resolver library that is used by pretty - much every unix, which fails if it ends up with a descriptor - above 256. We suspect there are other libraries that similar - limitations. So the code as of 1.2.1 takes a defensive stance - and tries to save descriptors less than 16 for use while - processing each request. This is called the low slack - line.
- -
Note that this shouldn't waste descriptors. If you really - are pushing the limits and Apache can't get a descriptor above - 16 when it wants it, it will settle for one below 16.
- -
In extreme situations you may want to lower the low slack - line, but you shouldn't ever need to. For example, lowering it - can increase the limits 240 described above under Solaris and - BSDI 2.0. But you'll play a delicate balancing game with the - descriptors needed to serve a request. Should you want to play - this game, the compile time parameter is - LOW_SLACK_LINE and there's a tiny bit of - documentation in the header file httpd.h.
- -
Finally, if you suspect that all this slack stuff is causing - you problems, you can disable it. Add -DNO_SLACK - to EXTRA_CFLAGS and rebuild. But please report it - to our Bug - Report Page so that we can investigate.
- - - - diff --git a/docs/manual/misc/fin_wait_2.html b/docs/manual/misc/fin_wait_2.html deleted file mode 100644 index 2e97e62907..0000000000 --- a/docs/manual/misc/fin_wait_2.html +++ /dev/null @@ -1,387 +0,0 @@ - - - - - - - Connections in FIN_WAIT_2 and Apache - - - - - - -
Connections in the FIN_WAIT_2 state and - Apache
- -
-
-
What is the FIN_WAIT_2 state?
- Starting with the Apache 1.2 betas, people are reporting - many more connections in the FIN_WAIT_2 state (as reported - by netstat) than they saw using older - versions. When the server closes a TCP connection, it sends - a packet with the FIN bit set to the client, which then - responds with a packet with the ACK bit set. The client - then sends a packet with the FIN bit set to the server, - which responds with an ACK and the connection is closed. - The state that the connection is in during the period - between when the server gets the ACK from the client and - the server gets the FIN from the client is known as - FIN_WAIT_2. See the TCP RFC for - the technical details of the state transitions. - -
The FIN_WAIT_2 state is somewhat unusual in that there - is no timeout defined in the standard for it. This means - that on many operating systems, a connection in the - FIN_WAIT_2 state will stay around until the system is - rebooted. If the system does not have a timeout and too - many FIN_WAIT_2 connections build up, it can fill up the - space allocated for storing information about the - connections and crash the kernel. The connections in - FIN_WAIT_2 do not tie up an httpd process.
-
- -
-
But why does it happen?
- There are numerous reasons for it happening, some of them - may not yet be fully clear. What is known follows. - -
Buggy clients and persistent connections
- Several clients have a bug which pops up when dealing with - persistent connections (aka - keepalives). When the connection is idle and the server - closes the connection (based on the KeepAliveTimeout), - the client is programmed so that the client does not send - back a FIN and ACK to the server. This means that the - connection stays in the FIN_WAIT_2 state until one of the - following happens: - -
-
The client opens a new connection to the same or a - different site, which causes it to fully close the older - connection on that socket.
- -
The user exits the client, which on some (most?) - clients causes the OS to fully shutdown the - connection.
- -
The FIN_WAIT_2 times out, on servers that have a - timeout for this state.
-
- -
If you are lucky, this means that the buggy client will - fully close the connection and release the resources on - your server. However, there are some cases where the socket - is never fully closed, such as a dialup client - disconnecting from their provider before closing the - client. In addition, a client might sit idle for days - without making another connection, and thus may hold its - end of the socket open for days even though it has no - further use for it. This is a bug in the browser or - in its operating system's TCP implementation.
- -
The clients on which this problem has been verified to - exist:
- -
-
Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE - i386)
- -
Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE - i386)
- -
Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
- -
MSIE 3.01 on the Macintosh
- -
MSIE 3.01 on Windows 95
-
- -
This does not appear to be a problem on:
- -
-
Mozilla/3.01 (Win95; I)
-
- -
It is expected that many other clients have the same - problem. What a client should do is - periodically check its open socket(s) to see if they have - been closed by the server, and close their side of the - connection if the server has closed. This check need only - occur once every few seconds, and may even be detected by a - OS signal on some systems (e.g., Win95 and NT - clients have this capability, but they seem to be ignoring - it).
- -
Apache cannot avoid these FIN_WAIT_2 - states unless it disables persistent connections for the - buggy clients, just like we recommend doing for Navigator - 2.x clients due to other bugs. However, non-persistent - connections increase the total number of connections needed - per client and slow retrieval of an image-laden web page. - Since non-persistent connections have their own resource - consumptions and a short waiting period after each closure, - a busy server may need persistence in order to best serve - its clients.
- -
As far as we know, the client-caused FIN_WAIT_2 problem - is present for all servers that support persistent - connections, including Apache 1.1.x and 1.2.
- -
A necessary bit of code introduced in 1.2
- While the above bug is a problem, it is not the whole - problem. Some users have observed no FIN_WAIT_2 problems - with Apache 1.1.x, but with 1.2b enough connections build - up in the FIN_WAIT_2 state to crash their server. The most - likely source for additional FIN_WAIT_2 states is a - function called lingering_close() which was - added between 1.1 and 1.2. This function is necessary for - the proper handling of persistent connections and any - request which includes content in the message body - (e.g., PUTs and POSTs). What it does is read any - data sent by the client for a certain time after the server - closes the connection. The exact reasons for doing this are - somewhat complicated, but involve what happens if the - client is making a request at the same time the server - sends a response and closes the connection. Without - lingering, the client might be forced to reset its TCP - input buffer before it has a chance to read the server's - response, and thus understand why the connection has - closed. See the appendix for more - details. - -
The code in lingering_close() appears to - cause problems for a number of factors, including the - change in traffic patterns that it causes. The code has - been thoroughly reviewed and we are not aware of any bugs - in it. It is possible that there is some problem in the BSD - TCP stack, aside from the lack of a timeout for the - FIN_WAIT_2 state, exposed by the - lingering_close code that causes the observed - problems.
-
- -
- What can I do about it? There are several possible - workarounds to the problem, some of which work better than - others. - -
Add a timeout for FIN_WAIT_2
- The obvious workaround is to simply have a timeout for the - FIN_WAIT_2 state. This is not specified by the RFC, and - could be claimed to be a violation of the RFC, but it is - widely recognized as being necessary. The following systems - are known to have a timeout: - -
-
FreeBSD - versions starting at 2.0 or possibly earlier.
- -
NetBSD version - 1.2(?)
- -
OpenBSD all - versions(?)
- -
BSD/OS 2.1, with - the - K210-027 patch installed.
- -
Solaris as of - around version 2.2. The timeout can be tuned by using - ndd to modify - tcp_fin_wait_2_flush_interval, but the - default should be appropriate for most servers and - improper tuning can have negative impacts.
- -
Linux 2.0.x and - earlier(?)
- -
HP-UX 10.x defaults - to terminating connections in the FIN_WAIT_2 state after - the normal keepalive timeouts. This does not refer to the - persistent connection or HTTP keepalive timeouts, but the - SO_LINGER socket option which is enabled by - Apache. This parameter can be adjusted by using - nettune to modify parameters such as - tcp_keepstart and tcp_keepstop. - In later revisions, there is an explicit timer for - connections in FIN_WAIT_2 that can be modified; contact - HP support for details.
- -
SGI IRIX can be - patched to support a timeout. For IRIX 5.3, 6.2, and 6.3, - use patches 1654, 1703 and 1778 respectively. If you have - trouble locating these patches, please contact your SGI - support channel for help.
- -
NCR's MP RAS Unix - 2.xx and 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it - is non-tunable at 600 seconds, while in 3.xx it defaults - to 600 seconds and is calculated based on the tunable - "max keep alive probes" (default of 8) multiplied by the - "keep alive interval" (default 75 seconds).
- -
Sequent's ptx/TCP/IP - for DYNIX/ptx has had a FIN_WAIT_2 timeout since - around release 4.1 in mid-1994.
-
- -
The following systems are known to not have a - timeout:
- -
-
SunOS 4.x does not - and almost certainly never will have one because it as at - the very end of its development cycle for Sun. If you - have kernel source should be easy to patch.
-
- -
There is a - patch available for adding a timeout to the FIN_WAIT_2 - state; it was originally intended for BSD/OS, but should be - adaptable to most systems using BSD networking code. You - need kernel source code to be able to use it.
- -
Compile without using - lingering_close()
- It is possible to compile Apache 1.2 without using the - lingering_close() function. This will result - in that section of code being similar to that which was in - 1.1. If you do this, be aware that it can cause problems - with PUTs, POSTs and persistent connections, especially if - the client uses pipelining. That said, it is no worse than - on 1.1, and we understand that keeping your server running - is quite important. - -
To compile without the lingering_close() - function, add -DNO_LINGCLOSE to the end of the - EXTRA_CFLAGS line in your - Configuration file, rerun - Configure and rebuild the server.
- -
Use SO_LINGER as an alternative to - lingering_close()
- On most systems, there is an option called - SO_LINGER that can be set with - setsockopt(2). It does something very similar - to lingering_close(), except that it is broken - on many systems so that it causes far more problems than - lingering_close. On some systems, it could - possibly work better so it may be worth a try if you have - no other alternatives. - -
To try it, add -DUSE_SO_LINGER - -DNO_LINGCLOSE to the end of the - EXTRA_CFLAGS line in your - Configuration file, rerun - Configure and rebuild the server.
- -
NOTE: Attempting to use - SO_LINGER and lingering_close() - at the same time is very likely to do very bad things, so - don't.
- -
Increase the amount of memory used for storing - connection state
- -
-
BSD based networking code:
- -
- BSD stores network data, such as connection states, in - something called an mbuf. When you get so many - connections that the kernel does not have enough mbufs - to put them all in, your kernel will likely crash. You - can reduce the effects of the problem by increasing the - number of mbufs that are available; this will not - prevent the problem, it will just make the server go - longer before crashing. - -
The exact way to increase them may depend on your - OS; look for some reference to the number of "mbufs" or - "mbuf clusters". On many systems, this can be done by - adding the line NMBCLUSTERS="n", where - n is the number of mbuf clusters you want - to your kernel config file and rebuilding your - kernel.
-
-
- -
Disable KeepAlive
- -
If you are unable to do any of the above then you - should, as a last resort, disable KeepAlive. Edit your - httpd.conf and change "KeepAlive On" to "KeepAlive - Off".
-
- -
-
Appendix
- -
Below is a message from Roy Fielding, one of the authors - of HTTP/1.1.
- -
Why the lingering close functionality is necessary with - HTTP
- The need for a server to linger on a socket after a close - is noted a couple times in the HTTP specs, but not - explained. This explanation is based on discussions between - myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and - John C. Mallery in the hallways of MIT while I was at W3C. - -
If a server closes the input side of the connection - while the client is sending data (or is planning to send - data), then the server's TCP stack will signal an RST - (reset) back to the client. Upon receipt of the RST, the - client will flush its own incoming TCP buffer back to the - un-ACKed packet indicated by the RST packet argument. If - the server has sent a message, usually an error response, - to the client just before the close, and the client - receives the RST packet before its application code has - read the error message from its incoming TCP buffer and - before the server has received the ACK sent by the client - upon receipt of that buffer, then the RST will flush the - error message before the client application has a chance to - see it. The result is that the client is left thinking that - the connection failed for no apparent reason.
- -
There are two conditions under which this is likely to - occur:
- -
-
sending POST or PUT data without proper - authorization
- -
sending multiple requests before each response - (pipelining) and one of the middle requests resulting in - an error or other break-the-connection result.
-
- -
The solution in all cases is to send the response, close - only the write half of the connection (what shutdown is - supposed to do), and continue reading on the socket until - it is either closed by the client (signifying it has - finally read the response) or a timeout occurs. That is - what the kernel is supposed to do if SO_LINGER is set. - Unfortunately, SO_LINGER has no effect on some systems; on - some other systems, it does not have its own timeout and - thus the TCP memory segments just pile-up until the next - reboot (planned or not).
- -
Please note that simply removing the linger code will - not solve the problem -- it only moves it to a different - and much harder one to detect.
-
-
- - - - diff --git a/docs/manual/misc/footer.html b/docs/manual/misc/footer.html deleted file mode 100644 index a418ad44c6..0000000000 --- a/docs/manual/misc/footer.html +++ /dev/null @@ -1,5 +0,0 @@ -
- -
Apache HTTP Server Version 2.1
- - diff --git a/docs/manual/misc/header.html b/docs/manual/misc/header.html deleted file mode 100644 index 3c93b3dce8..0000000000 --- a/docs/manual/misc/header.html +++ /dev/null @@ -1,6 +0,0 @@ -
- - -
Apache HTTP Server Version 2.1
-
- diff --git a/docs/manual/misc/known_client_problems.html b/docs/manual/misc/known_client_problems.html deleted file mode 100644 index cb27dfda5e..0000000000 --- a/docs/manual/misc/known_client_problems.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - - Apache HTTP Server Project - - - - - - -
Known Problems in Clients
- -
Over time the Apache Group has discovered or been notified - of problems with various clients which we have had to work - around, or explain. This document describes these problems and - the workarounds available. It's not arranged in any particular - order. Some familiarity with the standards is assumed, but not - necessary.
- -
For brevity, Navigator will refer to Netscape's - Navigator product (which in later versions was renamed - "Communicator" and various other names), and MSIE will - refer to Microsoft's Internet Explorer product. All trademarks - and copyrights belong to their respective companies. We welcome - input from the various client authors to correct - inconsistencies in this paper, or to provide us with exact - version numbers where things are broken/fixed.
- -
For reference, RFC1945 - defines HTTP/1.0, and RFC2068 - defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1 - server (with an optional HTTP/1.0 proxy).
- -
Various of these workarounds are triggered by environment - variables. The admin typically controls which are set, and for - which clients, by using mod_browser. Unless - otherwise noted all of these workarounds exist in versions 1.2 - and later.
- -
Trailing CRLF on - POSTs
- -
This is a legacy issue. The CERN webserver required - POST data to have an extra CRLF - following it. Thus many clients send an extra CRLF - that is not included in the Content-Length of the - request. Apache works around this problem by eating any empty - lines which appear before a request.
- -
Broken - keepalive
- -
Various clients have had broken implementations of - keepalive (persistent connections). In particular the - Windows versions of Navigator 2.0 get very confused when the - server times out an idle connection. The workaround is present - in the default config files:
- -
- BrowserMatch Mozilla/2 nokeepalive -
- Note that this matches some earlier versions of MSIE, which - began the practice of calling themselves Mozilla in - their user-agent strings just like Navigator. - -
MSIE 4.0b2, which claims to support HTTP/1.1, does not - properly support keepalive when it is used on 301 or 302 - (redirect) responses. Unfortunately Apache's - nokeepalive code prior to 1.2.2 would not work - with HTTP/1.1 clients. You must apply - this patch to version 1.2.1. Then add this to your - config:
- -
- BrowserMatch "MSIE 4\.0b2;" nokeepalive -
- -
Incorrect interpretation of - HTTP/1.1 in response
- -
To quote from section 3.1 of RFC1945:
- -
- HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to - indicate versions of the protocol. The protocol versioning - policy is intended to allow the sender to indicate the format - of a message and its capacity for understanding further HTTP - communication, rather than the features obtained via that - communication. -
- Since Apache is an HTTP/1.1 server, it indicates so as part of - its response. Many client authors mistakenly treat this part of - the response as an indication of the protocol that the response - is in, and then refuse to accept the response. - -
The first major indication of this problem was with AOL's - proxy servers. When Apache 1.2 went into beta it was the first - wide-spread HTTP/1.1 server. After some discussion, AOL fixed - their proxies. In anticipation of similar problems, the - force-response-1.0 environment variable was added - to Apache. When present Apache will indicate "HTTP/1.0" in - response to an HTTP/1.0 client, but will not in any other way - change the response.
- -
The pre-1.1 Java Development Kit (JDK) that is used in many - clients (including Navigator 3.x and MSIE 3.x) exhibits this - problem. As do some of the early pre-releases of the 1.1 JDK. - We think it is fixed in the 1.1 JDK release. In any event the - workaround:
- -
- BrowserMatch Java/1.0 force-response-1.0 - BrowserMatch JDK/1.0 force-response-1.0 -
- -
RealPlayer 4.0 from Progressive Networks also exhibits this - problem. However they have fixed it in version 4.01 of the - player, but version 4.01 uses the same User-Agent - as version 4.0. The workaround is still:
- -
- BrowserMatch "RealPlayer 4.0" force-response-1.0 -
- -
Requests use HTTP/1.1 - but responses must be in HTTP/1.0
- -
MSIE 4.0b2 has this problem. Its Java VM makes requests in - HTTP/1.1 format but the responses must be in HTTP/1.0 format - (in particular, it does not understand chunked - responses). The workaround is to fool Apache into believing the - request came in HTTP/1.0 format.
- -
- BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 - force-response-1.0 -
- This workaround is available in 1.2.2, and in a - patch against 1.2.1. - -
Boundary problems with - header parsing
- -
All versions of Navigator from 2.0 through 4.0b2 (and - possibly later) have a problem if the trailing CRLF of the - response header starts at offset 256, 257 or 258 of the - response. A BrowserMatch for this would match on nearly every - hit, so the workaround is enabled automatically on all - responses. The workaround implemented detects when this - condition would occur in a response and adds extra padding to - the header to push the trailing CRLF past offset 258 of the - response.
- -
Multipart - responses and Quoted Boundary Strings
- -
On multipart responses some clients will not accept quotes - (") around the boundary string. The MIME standard recommends - that such quotes be used. But the clients were probably written - based on one of the examples in RFC2068, which does not include - quotes. Apache does not include quotes on its boundary strings - to workaround this problem.
- -
Byterange requests
- -
A byterange request is used when the client wishes to - retrieve a portion of an object, not necessarily the entire - object. There was a very old draft which included these - byteranges in the URL. Old clients such as Navigator 2.0b1 and - MSIE 3.0 for the MAC exhibit this behaviour, and it will appear - in the servers' access logs as (failed) attempts to retrieve a - URL with a trailing ";xxx-yyy". Apache does not attempt to - implement this at all.
- -
A subsequent draft of this standard defines a header - Request-Range, and a response type - multipart/x-byteranges. The HTTP/1.1 standard - includes this draft with a few fixes, and it defines the header - Range and type - multipart/byteranges.
- -
Navigator (versions 2 and 3) sends both Range - and Request-Range headers (with the same value), - but does not accept a multipart/byteranges - response. The response must be - multipart/x-byteranges. As a workaround, if Apache - receives a Request-Range header it considers it - "higher priority" than a Range header and in - response uses multipart/x-byteranges.
- -
The Adobe Acrobat Reader plugin makes extensive use of - byteranges and prior to version 3.01 supports only the - multipart/x-byterange response. Unfortunately - there is no clue that it is the plugin making the request. If - the plugin is used with Navigator, the above workaround works - fine. But if the plugin is used with MSIE 3 (on Windows) the - workaround won't work because MSIE 3 doesn't give the - Range-Request clue that Navigator does. To - workaround this, Apache special cases "MSIE 3" in the - User-Agent and serves - multipart/x-byteranges. Note that the necessity - for this with MSIE 3 is actually due to the Acrobat plugin, not - due to the browser.
- -
Netscape Communicator appears to not issue the non-standard - Request-Range header. When an Acrobat plugin prior - to version 3.01 is used with it, it will not properly - understand byteranges. The user must upgrade their Acrobat - reader to 3.01.
- -
Set-Cookie header is - unmergeable
- -
The HTTP specifications say that it is legal to merge - headers with duplicate names into one (separated by commas). - Some browsers that support Cookies don't like merged headers - and prefer that each Set-Cookie header is sent - separately. When parsing the headers returned by a CGI, Apache - will explicitly avoid merging any Set-Cookie - headers.
- -
Expires headers and GIF89A - animations
- -
Navigator versions 2 through 4 will erroneously re-request - GIF89A animations on each loop of the animation if the first - response included an Expires header. This happens - regardless of how far in the future the expiry time is set. - There is no workaround supplied with Apache, however there are - hacks for - 1.2 and for - 1.3.
- -
POST without - Content-Length
- -
In certain situations Navigator 3.01 through 3.03 appear to - incorrectly issue a POST without the request body. There is no - known workaround. It has been fixed in Navigator 3.04, - Netscapes provides some information. - There's also - some information about the actual problem.
- -
JDK 1.2 betas lose - parts of responses.
- -
The http client in the JDK1.2beta2 and beta3 will throw away - the first part of the response body when both the headers and - the first part of the body are sent in the same network packet - AND keep-alive's are being used. If either condition is not met - then it works fine.
- -
See also Bug-ID's 4124329 and 4125538 at the java developer - connection.
- -
If you are seeing this bug yourself, you can add the - following BrowserMatch directive to work around it:
- -
- BrowserMatch "Java1\.2beta[23]" nokeepalive -
- -
We don't advocate this though since bending over backwards - for beta software is usually not a good idea; ideally it gets - fixed, new betas or a final release comes out, and no one uses - the broken old software anymore. In theory.
- -
Content-Type - change is not noticed after reload
- -
Navigator (all versions?) will cache the - content-type for an object "forever". Using reload - or shift-reload will not cause Navigator to notice a - content-type change. The only work-around is for - the user to flush their caches (memory and disk). By way of an - example, some folks may be using an old mime.types - file which does not map .htm to - text/html, in this case Apache will default to - sending text/plain. If the user requests the page - and it is served as text/plain. After the admin - fixes the server, the user will have to flush their caches - before the object will be shown with the correct - text/html type.
- -
MSIE Cookie - problem with expiry date in the year 2000
- -
MSIE versions 3.00 and 3.02 (without the Y2K patch) do not - handle cookie expiry dates in the year 2000 properly. Years - after 2000 and before 2000 work fine. This is fixed in IE4.01 - service pack 1, and in the Y2K patch for IE3.02. Users should - avoid using expiry dates in the year 2000.
- -
Lynx incorrectly asking for - transparent content negotiation
- -
The Lynx browser versions 2.7 and 2.8 send a "negotiate: - trans" header in their requests, which is an indication the - browser supports transparent content negotiation (TCN). However - the browser does not support TCN. As of version 1.3.4, Apache - supports TCN, and this causes problems with these versions of - Lynx. As a workaround future versions of Apache will ignore - this header when sent by the Lynx client.
- -
MSIE 4.0 mishandles Vary - response header
- -
MSIE 4.0 does not handle a Vary header properly. The Vary - header is generated by mod_rewrite in apache 1.3. The result is - an error from MSIE saying it cannot download the requested - file. There are more details in PR#4118.
- -
A workaround is to add the following to your server's - configuration files:
-
- BrowserMatch "MSIE 4\.0" force-no-vary -
- -
(This workaround is only available with releases - after 1.3.6 of the Apache Web server.)
- - - - diff --git a/docs/manual/misc/tutorials.html b/docs/manual/misc/tutorials.html deleted file mode 100644 index 020c760ec0..0000000000 --- a/docs/manual/misc/tutorials.html +++ /dev/null @@ -1,211 +0,0 @@ - - - - - - - Apache Tutorials - - - - - - -
Apache Tutorials
- -
- Warning: This document has not been updated - to take into account changes made in the 2.0 version of the - Apache HTTP Server. Some of the information may still be - relevant, but please use it with care. -
- -
The following documents give you step-by-step instructions - on how to accomplish common tasks with the Apache http server. - Many of these documents are located at external sites and are - not the work of the Apache Software Foundation. Copyright to - documents on external sites is owned by the authors or their - assignees. Please consult the official Apache - Server documentation to verify what you read on external - sites.
- -
Installation & Getting Started
- -
-
- Getting Started with Apache 1.3 (ApacheToday)
- -
- Configuring Your Apache Server Installation - (ApacheToday)
- -
- Getting, Installing, and Running Apache (on Unix) - (O'Reilly Network Apache DevCenter)
- -
Maximum - Apache: Getting Started (CNET Builder.com)
- -
- How to Build the Apache of Your Dreams (Developer - Shed)
-
- -
Basic Configuration
- -
-
- An Amble Through Apache Configuration (O'Reilly Network - Apache DevCenter)
- -
- Using .htaccess Files with Apache (ApacheToday)
- -
- Setting Up Virtual Hosts (ApacheToday)
- -
Maximum - Apache: Configure Apache (CNET Builder.com)
- -
- Getting More Out of Apache (Developer Shed)
-
- -
Security
- -
-
- Security and Apache: An Essential Primer - (LinuxPlanet)
- -
Using User - Authentication (Apacheweek)
- -
DBM - User Authentication (Apacheweek)
- -
- An Introduction to Securing Apache (Linux.com)
- -
- Securing Apache - Access Control (Linux.com)
- -
Apache Authentication - Part 1 - - Part 2 - - Part 3 - - Part 4 (ApacheToday)
- -
- mod_access: Restricting Access by Host (ApacheToday)
-
- -
Logging
- -
-
- Log Rhythms (O'Reilly Network Apache DevCenter)
- -
Gathering - Visitor Information: Customising Your Logfiles - (Apacheweek)
- -
Apache Guide: Logging - Part 1 - - Part 2 - - Part 3 - - Part 4 - - Part 5 (ApacheToday)
-
- -
CGI and SSI
- -
-
- Dynamic Content with CGI (ApacheToday)
- -
- The Idiot's Guide to Solving Perl CGI Problems - (CPAN)
- -
- Executing CGI Scripts as Other Users (LinuxPlanet)
- -
CGI - Programming FAQ (Web Design Group)
- -
Introduction to Server Side Includes - Part 1 - - Part 2 (ApacheToday)
- -
- Advanced SSI Techniques (ApacheToday)
- -
Setting - up CGI and SSI with Apache (CNET Builder.com)
-
- -
Other Features
- -
-
Content - Negotiation Explained (Apacheweek)
- -
Using - Apache Imagemaps (Apacheweek)
- -
- Keeping Your Images from Adorning Other Sites - (ApacheToday)
- -
Language - Negotiation Notes (Alan J. Flavell)
-
- -
If you have a pointer to an accurate and well-written - tutorial not included here, please let us know by submitting it - to the Apache Bug - Database.
- - - - -- 2.40.0

Using XSSI and ErrorDocument to - configure customized international server error responses

Index

More welcome!

Descriptors and Apache

Connections in the FIN_WAIT_2 state and - Apache

What is the FIN_WAIT_2 state?

But why does it happen?

Buggy clients and persistent connections

A necessary bit of code introduced in 1.2

Add a timeout for FIN_WAIT_2

Compile without using - lingering_close()

Use SO_LINGER as an alternative to - lingering_close()

Increase the amount of memory used for storing - connection state

Disable KeepAlive

Why the lingering close functionality is necessary with - HTTP

Apache HTTP Server Version 2.1

Apache HTTP Server Version 2.1

Known Problems in Clients

Apache Tutorials

Installation & Getting Started

Basic Configuration

Security

Logging

CGI and SSI

Other Features

Using XSSI and `ErrorDocument` to - configure customized international server error responses

Compile without using - `lingering_close()`

Use `SO_LINGER` as an alternative to - `lingering_close()`