Https bug

Hi,

I’ve noticed that my https instance of RT has an http:// address
(http://domain.co.uk/NoAuth/images/rt.jpg) for the rt.jpg file that
appears on the left of the “title bar”. Therefore, if the http address is
not accessible (connecting from the Internet for ex), the picture
doesn’t display.

Not a major problem really - but should be fixed sometime!

Yan
Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

ok fix it. :slight_smile: check your config.pm file near the bottom you will see the URL used for this image and other functions in RT. You
have it set to http:// now.

Greg
Greg Dickerson
Support Manager
O’Reilly & Associates, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
Phone:(707)827-7215----- Original Message -----
From: “Yan Fitterer” y.fitterer@ram.ac.uk
To: rt-users@lists.fsck.com
Sent: Tuesday, April 23, 2002 10:08 AM
Subject: [rt-users] https bug

Hi,

I’ve noticed that my https instance of RT has an http:// address
(http://domain.co.uk/NoAuth/images/rt.jpg) for the rt.jpg file that
appears on the left of the “title bar”. Therefore, if the http address is
not accessible (connecting from the Internet for ex), the picture
doesn’t display.

Not a major problem really - but should be fixed sometime!

Yan

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

|+ I’ve noticed that my https instance of RT has an http:// address
|+ (http://domain.co.uk/NoAuth/images/rt.jpg) for the rt.jpg file that
|+ appears on the left of the “title bar”. Therefore, if the http address is
|+ not accessible (connecting from the Internet for ex), the picture
|+ doesn’t display.
|+
|+ Not a major problem really - but should be fixed sometime!

So fix it! Edit your config.pm, change $WebBaseUrl to read:
$WebBaseUrl = “https://domain.co.uk”;

You’ll notice, that RT builds the path via:

$WebURL = $WebBaseURL . $WebPath . “/”;
$WebImagesURL = $WebURL.“/NoAuth/images/”;
$LogoURL = $WebImagesURL.“/rt.jpg”;

You see. It builds it from WebURL, which is built from $WebBaseURL and
$WebPath.

Its not a bug in RT, its a mistake in your config file.

-darrin

Er… Thanks for pointing me in the right direction, but unless I’m
much mistaken, the “fix” will be worse that the ill in my case. I run
both an http and https virtual hosts against the same RT instance,
so if I was to set $WebBaseURL, it would in all cases break one
server or the other. If I leave it to http: then when I access RT via
https, I get in some browsers a request to load “non-secure items”,
which then fails silently. If I set it to https, then every time the page
loads, I get a “license certificate” string of popup windows… Not
good.

However, experimenting with the $WebBaseURL, it seems that
setting it to “” works without breaking anything obvious.

Does anybody on the list knows a “Good Reason” not to set
$WebBaseURL to null?

Thanks again for pointing me in the right direction,
Yan---- On 23 Apr 2002, at 13:14, Darrin Walton wrote: ----

|+ I’ve noticed that my https instance of RT has an http:// address
|+ (http://domain.co.uk/NoAuth/images/rt.jpg) for the rt.jpg file
that |+ appears on the left of the “title bar”. Therefore, if the
http address is |+ not accessible (connecting from the Internet for
ex), the picture |+ doesn’t display. |+ |+ Not a major problem
really - but should be fixed sometime!

So fix it! Edit your config.pm, change $WebBaseUrl to read:
$WebBaseUrl = “https://domain.co.uk”;

You’ll notice, that RT builds the path via:

$WebURL = $WebBaseURL . $WebPath . “/”;
$WebImagesURL = $WebURL.“/NoAuth/images/”;
$LogoURL = $WebImagesURL.“/rt.jpg”;

You see. It builds it from WebURL, which is built from $WebBaseURL
and $WebPath.

Its not a bug in RT, its a mistake in your config file.

-darrin


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364

Yan Fitterer wrote:

However, experimenting with the $WebBaseURL, it seems that setting it
to “” works without breaking anything obvious.

Does anybody on the list knows a “Good Reason” not to set $WebBaseURL
to null?

Yes – the URLs on the website can be relative, but those in e-mail
messages obviously have to be absolute.

If you set $WebBaseURL to the null string then you will have to go
through every template which contains a line such as this:

{$RT::WebURL}Ticket/Display.html?id={$Ticket->id}

and fix it so that it becomes an absolute URL. Hardcoding the protocol
and servername into each template is one possibility, but may not be the
best long-term solution.

Smylers

Er… Thanks for pointing me in the right direction, but unless I’m
much mistaken, the “fix” will be worse that the ill in my case. I run
both an http and https virtual hosts against the same RT instance, so
if I was to set $WebBaseURL, it would in all cases break one server or
the other. If I leave it to http: then when I access RT via https, I
get in some browsers a request to load “non-secure items”, which then
fails silently. If I set it to https, then every time the page loads,
I get a “license certificate” string of popup windows… Not good.

Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
browser will use the scheme of the overall page. For example:

$WebBaseURL = “//rt.whereIam.com”;

(darren)

A sect or party in an elegant incognito devised to save a man from
the vexation of thinking.
– Ralph Waldo Emerson

darren chamberlain wrote:

Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
browser will use the scheme of the overall page. For example:

$WebBaseURL = “//rt.whereIam.com”;

That still won’t work in e-mails.

Smylers
GBdirect

darren chamberlain wrote:

Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
browser will use the scheme of the overall page. For example:

$WebBaseURL = “//rt.whereIam.com”;

That still won’t work in e-mails.

It will work for every called link within an HTML page as requested from
a browser. Modify the piece that is writing the email body to prepend
http: (i.e., “http:$WebBaseURL”), and then you solve the (bigger)
problem of mixed schemes within a page. I assume that we’re talking
about Scrip templates, so the change mentioned above need only be made
in a few localized places.

(darren)

The moment one gives close attention to anything, even a blade of
grass, it becomes a mysterious, awesome, indescribably magnificent
world in itself.
– Henry Miller

“dc” == darren chamberlain darren@boston.com writes:

dc> Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
dc> browser will use the scheme of the overall page. For example:

dc> $WebBaseURL = “//rt.whereIam.com”;

Wow… that’s a pretty cool trick. How compatible is this across
browsers? In particular, does it work for IE5, IE6, Opera5, Opera6,
Netscape4, Netscape6, Mozilla, and lynx-ssl?

I guess I could try it out, too.

“dc” == darren chamberlain darren@boston.com writes:

dc> Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
dc> browser will use the scheme of the overall page. For example:

dc> $WebBaseURL = “//rt.whereIam.com”;

Wow… that’s a pretty cool trick. How compatible is this across
browsers? In particular, does it work for IE5, IE6, Opera5, Opera6,
Netscape4, Netscape6, Mozilla, and lynx-ssl?

I got it from reading Slashcode, and it’s been in place on Slashdot for
at least a year. So… probably pretty available. I’ve only tested it
using Netscape 4.7x, Mozilla 0.9.*, and various lynxen.

(darren)

How is it possible to find meaning in a finite world, given my waist
and shirt size?
– Woody Allen

Vivek Khera khera@kcilink.com writes:

“dc” == darren chamberlain darren@boston.com writes:
dc> Simply remove the scheme from $WebBaseURL, and begin it with “//”; the
dc> browser will use the scheme of the overall page. For example:

dc> $WebBaseURL = “//rt.whereIam.com”;

Wow… that’s a pretty cool trick. How compatible is this across
browsers? In particular, does it work for IE5, IE6, Opera5, Opera6,
Netscape4, Netscape6, Mozilla, and lynx-ssl?

Relative URLs, including //example.com/rt, /rt and …/rt, have been in
every URL/URI standard I know of since RFC 1630 (Berners-Lee, June
1994). The only browser I know of that got any of them wrong was the
original NeXTStep browser T.B-L wrote at CERN (the very first WWW
browser, even before the CERN line-mode browser), which didn’t support
‘…’ in URLs.

I guess I could try it out, too.

And that’s what made the web the way it is today…

“The mere tendency of speech to encourage unlawful acts is not a
sufficient reason for banning it. […] The right to think is the
beginning of freedom, and speech must be protected from the government
because speech is the beginning of thought.” --Anthony Kennedy

“DR” == Dan Riley dsr@mail.lns.cornell.edu writes:

DR> Relative URLs, including //example.com/rt, /rt and …/rt, have been in
DR> every URL/URI standard I know of since RFC 1630 (Berners-Lee, June
DR> 1994). The only browser I know of that got any of them wrong was the

Hmmm. I guess I never considered it a relative URL; I usually
associated that with starting after the hostname part, but I guess it
generalizes all the way back to the protocol too… thanks for the
clarification.

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

Yesterday Dan Riley wrote:

Relative URLs, including //example.com/rt, /rt and …/rt, have been in
every URL/URI standard I know of since RFC 1630 (Berners-Lee, June
1994). The only browser I know of that got any of them wrong was the
original NeXTStep browser T.B-L wrote at CERN …

Brief testing yesterday (by coincidence, and nothing to do with ‘RT’)
uncovered what looks like a bug in the way ‘IE’ and ‘Mozilla’ handle
relative URLs. If you’re currently viewing this page:

http://www.example.com/Search/Listing.html

then by my reading of RFC 1630, a relative URL such as this:

New search

should resolve to this absolute URL:

http://www.example.com/Search/?ClearRestrictions=1

but in ‘IE’ and ‘Mozilla’ it comes out as the following, failing to
disgard the bit following the final slash:

http://www.example.com/Search/Listing.html?ClearRestrictions=1

(If my understanding of RFC 1630 is wrong and ‘IE’ and ‘Mozilla’ are
right, then ‘Lynx’ get’s it wrong cos it does it t’other one. Either
way round there seems to be a broken browser somewhere.)

Smylers
GBdirect

Smylers smylers@gbdirect.co.uk writes:

Yesterday Dan Riley wrote:

Relative URLs, including //example.com/rt, /rt and …/rt, have been in
every URL/URI standard I know of since RFC 1630 (Berners-Lee, June
1994). The only browser I know of that got any of them wrong was the
original NeXTStep browser T.B-L wrote at CERN …

I guess I should have mentioned that there have been URI/URL standards
since that supersede RFC 1630 (I probably also should have noted that
RFC 1630 is an “informational” RFC, not an IETF standard).

Brief testing yesterday (by coincidence, and nothing to do with ‘RT’)
uncovered what looks like a bug in the way ‘IE’ and ‘Mozilla’ handle
relative URLs. If you’re currently viewing this page:

http://www.example.com/Search/Listing.html

then by my reading of RFC 1630, a relative URL such as this:

New search

should resolve to this absolute URL:

http://www.example.com/Search/?ClearRestrictions=1

but in ‘IE’ and ‘Mozilla’ it comes out as the following, failing to
disgard the bit following the final slash:

http://www.example.com/Search/Listing.html?ClearRestrictions=1

(If my understanding of RFC 1630 is wrong and ‘IE’ and ‘Mozilla’ are
right, then ‘Lynx’ get’s it wrong cos it does it t’other one. Either
way round there seems to be a broken browser somewhere.)

Looks like you’ve found a spot where the standards haven’t been
consistent. I agree with your reading of RFC 1630. However, RFC 1630
was superseded by RFC 1808 in June 1995, and 1808 clearly agrees with
IE and Mozilla. RFC 1808, in turn, was “updated” by RFC 2396 August
1998, and RFC 2396 appears to say that “?ClearRestrictions=1” isn’t a
valid relative URI–2396 has the BNF:

  relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]
  rel_path      = rel_segment [ abs_path ]
  rel_segment   = 1*( unreserved | escaped |
                      ";" | "@" | "&" | "=" | "+" | "$" | "," )

‘?’ doesn’t appear in rel_segment, and the stuff in relativeURI before
‘?’ looks like it can’t be empty. The examples in appendix C includes
a “?..” example, which says that given

  http://a/b/c/d;p?q

it should resolve as

  ?y            =  http://a/b/c/?y

However, according to Roy Fielding (the primary author), this is an
error. Examples of Resolving Relative URLs says:

?y = http://a/b/c/d;p?y [R,X,5]*Bug in RFC examples
http://a/b/c/?y [1,2,3,4]

so the 2396 example is incorrect, the answer is supposed to be
http://a/b/c/d;p?y”, and many browsers get it wrong. I guess this
also means the BNF is wrong.

What a mess!

Conclusion? IE and Mozilla are right, Lynx is wrong, as are many
other browsers–enough that “don’t do that” is probably the only
safe answer. I’d try to use “Listing.html?ClearRestrictions=1” or
“./?ClearRestrictions=1”, depending on the desired behavior.

“The mere tendency of speech to encourage unlawful acts is not a
sufficient reason for banning it. […] The right to think is the
beginning of freedom, and speech must be protected from the government
because speech is the beginning of thought.” --Anthony Kennedy

Hi,

Thought I’d share the resolution to my original problem (mixing http & https while
keeping all web links and Email templates working):

The answer uses the relative URI scheme (//domain.name/path/etc), but the
solution is to apply that to the $WebImagesURL config var. If one sets it to
something like:

//domain.com/NoAuth/images

then everything works, I believe. The web urls get worked out OK by the browsers,
and that doesn’t affect those included in email templates, thus solving the original
problem without affecting anything else.

As we say in French, CQFD!

Bye
Yan

PS: CQFD = “Ce Qu’il Fallait Demontrer”, or in other words, “Gotcha!”---- On 25 Apr 2002, at 6:14, Dan Riley wrote: ----

Smylers smylers@gbdirect.co.uk writes:

Yesterday Dan Riley wrote:

Relative URLs, including //example.com/rt, /rt and …/rt, have been in
every URL/URI standard I know of since RFC 1630 (Berners-Lee, June
1994). The only browser I know of that got any of them wrong was the
original NeXTStep browser T.B-L wrote at CERN …

I guess I should have mentioned that there have been URI/URL standards
since that supersede RFC 1630 (I probably also should have noted that
RFC 1630 is an “informational” RFC, not an IETF standard).

Brief testing yesterday (by coincidence, and nothing to do with ‘RT’)
uncovered what looks like a bug in the way ‘IE’ and ‘Mozilla’ handle
relative URLs. If you’re currently viewing this page:

http://www.example.com/Search/Listing.html

then by my reading of RFC 1630, a relative URL such as this:

New search

should resolve to this absolute URL:

http://www.example.com/Search/?ClearRestrictions=1

but in ‘IE’ and ‘Mozilla’ it comes out as the following, failing to
disgard the bit following the final slash:

http://www.example.com/Search/Listing.html?ClearRestrictions=1

(If my understanding of RFC 1630 is wrong and ‘IE’ and ‘Mozilla’ are
right, then ‘Lynx’ get’s it wrong cos it does it t’other one. Either
way round there seems to be a broken browser somewhere.)

Looks like you’ve found a spot where the standards haven’t been
consistent. I agree with your reading of RFC 1630. However, RFC 1630
was superseded by RFC 1808 in June 1995, and 1808 clearly agrees with
IE and Mozilla. RFC 1808, in turn, was “updated” by RFC 2396 August
1998, and RFC 2396 appears to say that “?ClearRestrictions=1” isn’t a
valid relative URI–2396 has the BNF:

  relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]
  rel_path      = rel_segment [ abs_path ]
  rel_segment   = 1*( unreserved | escaped |
                      ";" | "@" | "&" | "=" | "+" | "$" | "," )

‘?’ doesn’t appear in rel_segment, and the stuff in relativeURI before
‘?’ looks like it can’t be empty. The examples in appendix C includes
a “?..” example, which says that given

  http://a/b/c/d;p?q

it should resolve as

  ?y            =  http://a/b/c/?y

However, according to Roy Fielding (the primary author), this is an
error. Examples of Resolving Relative URLs says:

?y = http://a/b/c/d;p?y [R,X,5]*Bug in RFC examples
http://a/b/c/?y [1,2,3,4]

so the 2396 example is incorrect, the answer is supposed to be
http://a/b/c/d;p?y”, and many browsers get it wrong. I guess this
also means the BNF is wrong.

What a mess!

Conclusion? IE and Mozilla are right, Lynx is wrong, as are many
other browsers–enough that “don’t do that” is probably the only
safe answer. I’d try to use “Listing.html?ClearRestrictions=1” or
“./?ClearRestrictions=1”, depending on the desired behavior.


“The mere tendency of speech to encourage unlawful acts is not a
sufficient reason for banning it. […] The right to think is the
beginning of freedom, and speech must be protected from the government
because speech is the beginning of thought.” --Anthony Kennedy


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Yan Fitterer
IT Manager, Royal Academy of Music
E-mail : y.fitterer@ram.ac.uk
Marylebone Rd, London, NW1 5HT
Phone (+44) 20 7873 7365 Fax (+44) 20 7873 7364