Bugzilla

Comment 6

•

22 years ago

-> parser

Assignee: new-network-bugs → harishd

Status: UNCONFIRMED → NEW

Component: Networking → Parser

Ever confirmed: true

QA Contact: jimmylee → moied

Christopher Hoess (gone)

Comment 7

•

22 years ago

How is this a bug in the HTML (rather than URL) Parser? And reporter, 
could you attach a simple testcase?

Robert Todd

Reporter

Comment 8

•

22 years ago

Here is a dynamically generated page that works in IE and Naviagator 4.79
the two script files and the CSS included do not work on an NT server because a 
Java FileSeperator was used to create the last slash in the chain.  When this 
application is run and a Unix server it works fine, unfortuneately many 
Citigroup apps are run on both types of servers.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<title>Renewals Start</title>
	<script language="javascript1.2"  src="\pfslic\renewals\redirect.js">
  	</script>
	<script language="javascript1.2"  
src="\pfslic\renewals\errorWarning.js">
	</script>
	<script language="javascript1.2">
		function submitForm()
		{
			var aForm = document.forms[0];
			aForm.submit();
		}
  	</script>
	<link REL=StyleSheet HREF="\pfslic\renewals\indRen.css" TYPE="text/css">

</head>
<body onLoad="javascript:errorWarning(''); return true">
<!-- Start of FORM -->
<!--<form method=post> -->
<form method=post action="/pfslic/IndRenDriverServlet">  
<input type=hidden name=pageName value=RenewalsStart>
<table width=100% cellpadding=0 cellspacing=0>
<tr><td width=100% height=1 bgcolor=336699><img src="/pfslic/spacer.gif" 
height=1></td></tr>
<tr><td class="font"></td></tr>
<tr><td width=100% height=1 bgcolor=336699><img src="/pfslic/spacer.gif" 
height=1></td></tr>
<tr><td class=b>You are on page: <font color=red>Start</font></td></tr>
</table>
<p class="head">Renewals Start</p>
<br>

<br>
<table>
	<tr>
		<td class="b">Select a Country:</td>
		
			<td class="font"><input type="radio" name="radCountry" 
onclick="submitForm();"
			             value="CAN" >Canada</td>
		
			<td class="font"><input type="radio" name="radCountry" 
onclick="submitForm();"
			             value="USA" checked>United States</td>
		
	</tr>
	<tr><td class="font">&nbsp;</td></tr>

	<tr><td class="font">&nbsp;</td></tr>
	<tr>
		<td class="b">Select a Desk Code:</td>
		<td class="font">
			<select name="selDeskCode">
				
					<option value="RPT" >RPT</option>
								
			</select></td>
	</tr>

</table>
<table width=100%>
	<tr><td class="fixed"><input type="submit" name="submitButton" 
width="150" style="width:150px" value="Submit"></td></tr>
</table>
</form>
</body>
</html>

Comment 9

•

22 years ago

Andreas, can you possibly take a look at this?  Thanks.

Assignee: harishd → andreas.otte

Component: Parser → Networking

QA Contact: moied → tever

Assignee

Comment 10

•

22 years ago

I'm sorry Robert, but currently there will be no help for your legacy
applications with mozilla. Using \ in urls as dir separator is simply wrong and
violates some RFCs (2396 for example). If we would support \ as dir separator it
would cause pages not being loaded that (rightfully) use \ as part of the filename. 

We usually try to support html/url-quirks as long as they do not violate rfcs,
but in this case there is no way unless we do a total redesign of the urifixup code.

For now this belongs to tech evangelism in my opinion.

Comment 11

•

22 years ago

resolving INVALID again then.  Not enough support for this.

Status: NEW → RESOLVED

Closed: 22 years ago → 22 years ago

Resolution: --- → INVALID

Comment 12

•

22 years ago

bug# 178241 is a newer RFE asking for support for this.  It probably could be
marked a dupe but I'll leave it open since its asking for an interface change.

benc

Comment 13

•

22 years ago

VERIFIED:
this issue comes up occassionally, but the objections still seem to outweight
the pros.

Status: RESOLVED → VERIFIED

QA Contact: tever → benc

Josh Birnbaum

Comment 14

•

22 years ago

*** Bug 192363 has been marked as a duplicate of this bug. ***

Comment 15

•

22 years ago

broken site:

http://wwwesterni.unibg.it/siti_esterni/rls/e-texts.htm#essays -- links have "\"
http://wwwesterni.unibg.it/siti_esterni/rls/essays\plains\ap-7.htm -- doesn't work
http://wwwesterni.unibg.it/siti_esterni/rls/essays/plains/ap-7.htm -- works

People who claim there are sites out there with "\" in their filenames, please
provide evidence.

In any case, what the heck does IE do? Does it change all "\" to "/" ??? If so,
then all of those sites with "\" in the filename will be broken in IE on
windows. Or, does IE instead try it both ways?

I think Moz should, at least, attempt to translate the "\" to "/" if it gets a
404, then everyone will be happy. This is a pretty major bug, actually, that
makes some site /completely/ broken because most users aren't smart enough to
notice the backslashes and fix them.

Status: VERIFIED → REOPENED

Resolution: INVALID → ---

Comment 16

•

22 years ago

*** Bug 164944 has been marked as a duplicate of this bug. ***

Comment 17

•

22 years ago

There was an earlier complication because on Win32, Moz converted but on other
OSes it didn't. The solution at the time was to stop converting on all
platforms. That's good, inconsistency is bad, but I think the solution should be
to convert or attempt on 404 to convert, on all platforms. Note that /none/ of
the related bugs list any /real/ URLs that use backslashes.

Related bugs: 
Bug 32895   Converting \ to / in urls on windows only (was: RFC 2396 $2.4.3
non-compliance?)
Bug 34239   cleanup - stop converting \ to / for win32 url parsing *comment #16*
Bug 73701   Enhancement: It would be nice and very handy, if Mozilla could
handle "/" as a "\" and in other direction too.
Bug 93197   [RFE] URL: automatic"\" to "/" conversion (w/prefBug 190821  URL:
paths with backslash (\) incorrectly
Bug 122270  URL: Remove all conversion from \ to / on windows in
nsDefaultURIFixup except when a real filepath is identified

I just looked at all the bugs with "\" in the summary and there was not a single
one claiming that something was busted because moz converted the / to a \ ...
despite that moz on windows was running with that conversion in place for quite
a long time. If the Mozilla goal is to be able to work properly with any pages
that IE can handle, this needs to be fixed.

Summary: Windows backslash file seperator not recognized → Windows backslash file separator not recognized

benc

Comment 18

•

22 years ago

If you want to file a separate bug about 404 handling w/ these URLs, you should.
I'll make my objections in that bug.

Assignee

Comment 19

•

22 years ago

Bug 32895 included a link to a testcase which fails when \ is converted to / if
I remember correctly. In my opinion we don't want to be able to handle those
pages on first call because doing so would break an RFC. Maybe with a totally
rewritten uri-fixup code which trys different approaches we can do that but only
after we tried with \ as normal character.

Comment 20

•

22 years ago

Re: comment #18: Bug 192816 Retry on 404 if the URL contains "\"

Re: comment #19: Testcases are not the real world. According to my sifting
through many bugs, there has never once been a URL reported in the wild with a \
that was deliberated intended to be %5C. Obviously the lack of evidence does not
prove the reverse, /but/ there is a substantial number of pages out there /right
now/ that don't work in Mozilla but work in IE (no workaround). That is a Bad
Thing. In page rendering, Mozilla is humble, it should be humble in URL handling
as well.

Assignee

Comment 21

•

22 years ago

You won't get me to implement anything that violates an RFC and could stop pages
coded in conformance with RFCs from being loaded, even if that is only
theoretical, which I don't believe. In bug 32895 there is a link to a webpage
which you will not see if you simply convert all \ to /. One page is enough,
even the theoretical possibility is enough. 

I have however nothing against trying to convert \ to / *after* the first or a
consecutive attempt to load a page or an image failed. That rewrite of the uri
fixup code is most certainly futured, if it is filed at all.