Favorites link won't work, but typed in URL does



We're seeing a very strange error. We have a local WAS server running, and
have a URL mapped to it - something like dev.abc.company.com. If we click
the Favorites link (http://dev.abc.company.com) we get an error (no message
returned so I'm not sure what it is). If we type that exact same URL into
the browser, it works perfectly. Some of the trace logs imply that the
favorites link is doing a GET vs the typed in link is doing a POST. We're
not passing alot of data around, for now just hardcoded a login id and
automatically submit the page onLoad. but in incase the login id was not
collected up, we put some error trapping in the backend code to see if it's
null, and it was not.

One other thing is that we see a 304 Not Modifed message in some of the logs
when the link is clicked. We just see a 200 OK message when the url is typed

Any ideas why a favorites Link would behave differently than typing the URL
in directly? I've searched the net and the MS Knowledge base and dont' see
any info on this.


Rob ^_^

Hi Nancy,

This is just a guess so I may be wrong. Check the properties of the Favorite
(right click and select Properties). Make sure that the 'Make this page
available offline' option is unchecked.

Perhaps you are deleting offline content when you clear the cache and the
Favorite is looking for the offline copy?



Hi Rob,

Thanks for the response, but the box was unchecked, so I guess it wasn't
that. It's the strangest problem. If we use the link, none of the data on the
page that is required is collected up and put in the request object, so it
fails. But if we open the short cut, copy the exact URL and paste it into a
browser and click GO, it works fine. Very annoying!




Incase anyone is really up for a challenge on this one, here is more info. I
ran the urls, both via a Favorite menu link and typed in url, and using
ieHTTPHeaders software was able to see a bit more about what was happening.

Aside from the favorite link issuing a GET instead of a PUT, I found out
that the link tried to submit the frame set, not the jsp page within the

Basically we have a frameset with date headers, nav bar etc, and the main
content frame contains a jsp that onLoad, submits itself. This page has
action="servlet/Controller" and method="POST" . If we type in the URL, the
http header trace shows that a POST was issued to the servlet from the main
jsp, the referrer being the main jsp page. All data was collected up and all
works fine.

If we use the Favorites link, the log shows a GET was issued to the servlet,
and the referrer was the frameset, which has no method or action, so it
defaults to GET. I don't even know how it knows about the servlet, since it's
not mentioned anywhere in the frameset html. No data was collected up, so
even though it managed to find the servlet, it has not data to tell it what
to do.

Anybody have any ideas on what the heck is going on?? It's running on WAS
5.1 on an intranet.


Rob ^_^

Hi Again,

I am no Java expert, but as soon as you mentioned framesets I had a thought.

If this only happens on one computer then check that you have 'Navigate
sub-frames across different domains' enabled in the security settings for
the Zone where you have placed your site (Intranet?)

Just a guess.


Thanks for the suggestion, but I finally figured it out. I'll post the
solution here, incase anyone else encounters it. I found that 2 url's with
the exact same text in them actually contained very different values under
the covers. I discovered this when I attemped to email this links to a
co-worker. One link had a url value of the correct site. That one worked,
the one that didn't work had additional information, such as baseurl. I
think since the site is in test mode, and we don't actually login, when the
frameset loads, the first test page submits itself (pretend login) and it's
redirected to the 2nd page. This is what is bookmarked when you do an "Add to
Favorites" from here. The URL actually contained other values, so when that
link was clicked, it tried to redirect to the 2nd page, and didn't collect up
the data, etc. from the original 1st page. So it was very odd. I think once
our landing page is a login page, and that page is bookmarked, the url will
be ok. We proved this out.

Here is what the 2 urls contained (I was only able to see this when i did a
view on the attached URL in a lotus notes email)



the one that worked was created manually by adding a short cut to the
favorites folder and entering the url. The one that failed was bookmarked
from the 2nd redirected page. For some reason that issued a GET to the
servlet/Controller and therefore didn't collect the data required.

So it was a challenge, but I figured it out. If anyone else can use this
info, good luck!.


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question