SSI stripping end paragraph tag if no blank line at end

VERIFIED INVALID

Status

Camino Graveyard
General
--
major
VERIFIED INVALID
12 years ago
12 years ago

People

(Reporter: Hector Cabarcas, Unassigned)

Tracking

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2

A server-side include which does not contain a blank line after an ending paragraph tag (</p>) will strip that ending tag when pulled into the page calling the include. If you DO include the blank line after the include's content, the ending tag will show up in the calling page's code. 

Reproducible: Always

Steps to Reproduce:
1. Create a server-side include and enter the following in the contents of the file "<p>This is a test paragaph.</p>" Make sure to NOT include a carriage return (new blank line) after the end tag.
2. Create a page that calls the include.
3. View the calling page in a browser and look at the source code.

Actual Results:  
If you DIDN'T include the carriage return (new blank line) you WILL NOT see the ending tag in your view source window.

Expected Results:  
The closing tag should appear in the view source window of the calling page. The closing tag should appear whether or not there's a carriage return placed at the end of the SSI.

I'm posting this as a Severity:Major because a page will fail to validate as valid XHTML because the closing tag is missing.

Comment 1

12 years ago
Server side includes are, as the name says, server side--browsers have no control over how servers interpret them.

This would be a bug in whatever web server you are seeing this behavior with, not Camino (or any other browser).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

12 years ago
(In reply to comment #1)
> Server side includes are, as the name says, server side--browsers have no
> control over how servers interpret them.
> 
> This would be a bug in whatever web server you are seeing this behavior with,
> not Camino (or any other browser).
> 

You are correct. I've tested it on Opera and Safari and the results are the same. Thanks for clearing that up.
You need to log in before you can comment on or make changes to this bug.