Received: (qmail 43975 invoked by uid 65534); 17 Jan 2000 11:22:22 -0000 Message-Id: <20000117112222.43974.qmail@locus.apache.org> Date: 17 Jan 2000 11:22:22 -0000 From: Gary Martin Reply-To: g.martin@shu.ac.uk To: submit@bugz.apache.org Subject: Apache allows faulty URLs like http://server/index.html/dir_name/ for SSI parsed files X-Send-Pr-Version: 3.110 >Number: 5598 >Category: mod_include >Synopsis: Apache allows faulty URLs like http://server/index.html/dir_name/ for SSI parsed files >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Quarter: >Keywords: >Date-Required: >Class: duplicate >Submitter-Id: apache >Arrival-Date: Mon Jan 17 03:30:00 PST 2000 >Closed-Date: Wed May 24 14:02:23 PDT 2000 >Last-Modified: Wed May 24 14:02:23 PDT 2000 >Originator: g.martin@shu.ac.uk >Release: 1.3.9 >Organization: >Environment: SunOS apple 5.7 Generic 106541-04 sun4u SUNW,Ultra-5_10 >Description: For server-side parsed files Apache appears to truncate URLs for which the first part of the URLs is correct. E.g. any URL that begins http://server/index.html/... or contains a space results in the first part of the file being returned. If an html file contains a faulty link that results in the same file being displayed. This causes robots accessing the page to continuously loop. I am not able to switch off parsing of HTML file on my site. Nor can I guarantee that all the links are free of erros/spaces etc. Can you suggest a workaround please? >How-To-Repeat: Go to http://www.shu.ac.uk/schools/cms/peu/docs/forms.html and click on PEU. This points at a non-existesnt URL but displays the forms.html file again. >Fix: >Release-Note: >Audit-Trail: From: "Martin, Gary J" To: "'marc@locus.apache.org'" Cc: "'apbugs@Apache.Org'" Subject: RE: mod_include/5598 Date: Wed, 19 Jan 2000 15:03:32 -0000 Marc, I can't find any other replies to similar queries. A search for mod_include on http://bugs.apache.org/? doesn't come up with any. Incidentally the 'Maximum number of records to return' on that page doesn't seem to work - it always returns just 20. I understand that you may have reasons to support this behaviour deliberately. Why just do it for server-parsed files though? Gary -----Original Message----- From: marc@locus.apache.org [mailto:marc@locus.apache.org] Sent: 17 January 2000 16:28 To: G.Martin@shu.ac.uk; marc@locus.apache.org; apache-bugdb@apache.org Subject: Re: mod_include/5598 Synopsis: Apache allows faulty URLs like http://server/index.html/dir_name/ for SSI parsed files State-Changed-From-To: open->closed State-Changed-By: marc State-Changed-When: Mon Jan 17 08:27:14 PST 2000 State-Changed-Why: This is not a bug, but a feature. If you have mod_include enabled then Apache does this by design. There are already dozens of "bug reports" about the same thing, with the reasons why it does it explained clearly. State-Changed-From-To: open-closed State-Changed-By: coar State-Changed-When: Wed May 24 14:02:19 PDT 2000 State-Changed-Why: [This is a standard response.] This issue has been reported before; please search the FAQ and the bug database. Thanks for using Apache! Class-Changed-From-To: sw-bug-duplicate Class-Changed-By: coar Class-Changed-When: Wed May 24 14:02:19 PDT 2000 >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]