In article
<out-539399f2.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk>,
   Chris Young <chris.yo...@unsatisfactorysoftware.co.uk> wrote:
> On Sat, 07 Jun 2014 19:58:41 +0100, Richard Torrens (lists) wrote:

> > After a bit more experimenting, it is caused by the line:
> > 
> > <P><a href="http://<!--#echo var="HTTP_HOST" --><!--#echo
> > var="DOCUMENT_URI" -->">Top of page</a>

> Ah, right.  I know exactly what the problem is and what causes it.

> NetSurf now rejects invalid URLs.  By "invalid" I mean, anything
> containing characters that are not permitted either in old-style ASCII
> names, or in IDNA, plus some other validity checking mostly related to
> IDNs.

> Previously NetSurf would percent-encode the host and return that, so
> you'd end up with a garbage URL.  Now it rejects the URL outright. 
> However, it appears the layouting can't cope with that.  I did some
> extensive searching when I made this change initially and was unable
> to track down why this was causing the layouting to fail - ideally, a
> broken URL shouldn't cause termination of the layouting process, it
> should only make the problem link go nowhere.

> I considered this low risk at the time as it is incredibly rare to
> encounter a link to a URL which doesn't conform to the rules.

> However, obviously it does need to be fixed, so if you can raise it on
> the bugtracker that'd be grand.

Good luck with that.

I'm plagued with this BocConvert as well as told in my thread "Username
and Password problem".

Daniel showed some interest and asked for information and I've tried
everything to get it to him and after (in total) a couple of hours trying
I've given up.

The log from my Netsurf seems to say that it bombs out BoxConvert because
it encounters the character 5f presumably hex or &5F. I have searched
through the relevant html on my intranet and no 5F anywhere and certainly
not in a page url.

Mine is triggered not by the web page as such but by the security username
and password on items inside one folder on my Cherokee driven Intranet.    

This started to happen for me with build 1950 and has persisted ever since
but builds up to and including 1949 did not have the problem. I would not
be surprised if the problem in this thread started with also 1950.

As regards reporting the problem, I found this an obstacle course and no
doubt.

Firstly, I was asked for a log file from netsurf which after some reading
and testing I managed to generate. I possibly wrongly emailed it to the
mailing list. I was told it was being help for the next moderator as it
was a little too big.

So I emailed Daniel to his email address with the file, no reply.

He also asked me for something in cgi. Err what?

And the config file from Cherokee for which I've asked what's the file
name and where it may be in the structure but had no reply.

The I thought maybe I should look into this bug tracker whatsit, that when
the problems started.

Registration kept bombing out or doing nothing and I had to use a PC to
get this done. I then logged in using the ARMiniX and Netsurf filled in a
report and then found in Netsurf I could not attach a log file.

I logged in on the pc, filled min the forms all again, attached the file,
hit send and it bombed out again.

At this point I walked away pretty wound up if I'm honest.



Cheers,

Bob.


Reply via email to