111026 - ehostweb17.epnet.com - EbscoHost does not work with non-commercial Mozilla 5

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Jonadab the Unsightly One (Nathan Eady)]

Reproducable:
    100% with 0.9.5 on MacOS 9 or Windows 98, with 
    or without the Java plugin installed, with or 
    without NS6 installed.  Java and Javascript
    are enabled in all cases (as required).
NOT Reproducable:
    With Netscape 6.1, with the Java plugin installed.
    Will try with 0.9.4 at home this evening, to 
    verify that this is not a regression.

Steps to Reproduce:

1.  Login to EbscoHost.  
2.  Select one or more databases (e.g., MasterFile Premier)
3.  Click on the "Enter" graphic/button.
4.  Type some search terms in the box, and turn on one
    of the search-type radio buttons.
5.  Click on the "Search" graphic/button.

Expected Results:  
     Should perform the search and return a web page
     listing them.  

Actual Results:  
     "javascript:form_submit('BasicSearch.asp');"
     flashes briefly in the status bar and then
     it says "Document: Done (0 secs)", but the
     search form remains, with no results.

Comment 1

[Jonadab the Unsightly One (Nathan Eady)]

Did some additional testing.  EbscoHost works correctly with 
Netscape 6.2 on Win98, does NOT work with 0.9.4 on the same
system.  Also does not work on 0.9.6 (behavior is the same
as on 0.9.5).   This very much appears to depend on the
commercial branding, as odd as that seems.  

If someone at mozilla.org needs access to EbscoHost to
confirm this, I can issue you a library card number that 
will give you access through OPLIN.  I'd need name, 
address, and birthdate.  

Comment 2

[Bob Clary [:bc] (inactive)]

Jonadab, it sounds like sniffing the user agent string for Netscape. If you can
get a contact email for us, that would be very helpful.

Comment 3

[Jonadab the Unsightly One (Nathan Eady)]

Netscape 6 uses a different UA string?  I didn't know thaaat...

Confirmed:  If I put a user-agent override in prefs.js to
            force use of the UA string that NS6.2 uses, the
            page works as expected in the unbranded 0.9.6,
            on the same PC on which this failed the other day.

> If you can get a contact email for us

I believe I can do that at work this afternoon.  

Comment 4

[Bob Clary [:bc] (inactive)]

Jonadab, since you are contacting them I will assign this to you. Once you
contact them, please mark this bug ASSIGNED and set the milestone to Jan so we
can follow this site up to see if they have fixed their sniffing.

You can refer them to:
http://developer.netscape.com/evangelism/docs/articles/find-gecko/

Comment 5

[Jonadab the Unsightly One (Nathan Eady)]

I confirmed this on MacOS 9 also:  the User-Agent string is most
definitely the decisive factor.  No question, Ebsco is sniffing.

The only email contact I can find is the one on their website
that is shown, for example, when you exit the service:
For Technical Support or comments on EBSCOhost contact [e-mail]

I thought I would have an additional contact address in this manilla
folder, but I don't seem to.  I _do_ have a support address for OPLIN, 
through whom all the public libraries in Ohio have their subscriptions 
to the EbscoHost service.  It is predictable:  [e-mail]

Comment 6

[Jonadab the Unsightly One (Nathan Eady)]

Oh, BTW, Bob:  okay, I'll go ahead and contact them.

Comment 7

[Jonadab the Unsightly One (Nathan Eady)]

Sent a note to them a moment ago.  Marking assigned, setting target as directed.

Comment 8

[Jonadab the Unsightly One (Nathan Eady)]

Ebsco has denied doing sniffing that could have this
effect, so to prove them wrong, I saved copies of
the page in question as retrieved using the unchanged
UA string on one PC (where Ebsco doesn't work) and
using the Netscape UA string on another PC (where
Ebsco does work).  Then I did fc /N /I a.htm b.htm
and found...  *no* differences.  But with the UA string
set to match that of Netscape 6.2, the script sets
one radio button automatically, and clicking "Search"
results in a search; with the default UA string, the
radio buttons are all clear until you click one, and
clicking "Search" does nothing.

So... same browser, same content, different UA string,
different behavior.  This set me thinking whether the
Java plugin could somehow be checking the UA string...

Wait...  No, it *is* Ebsco's doing, I found it; the
Javscript in the page itself appears to do the sniffing
retroactively.  Here:

function searchRange(SearchValue)
{
 top.bodyframe.location.href='resultList.asp?booleanTerm='+escape(SearchValue);
}

I'm not sure what this is intended to accomplish, but there
it is, plain as day, "etscape".  I'll get back to the guy at 
Ebsco with this new info.  

Comment 9

[Jonadab the Unsightly One (Nathan Eady)]

Aaargh!  I read that wrong; there's no reference to "Netscape" 
there. at all.  

However, I also noticed that the content is a frameset.  I
will check the source for the individual frames for any
disparities that depend on the UA string...
[does so]

Aha!  Yes, the actual problem is in basicsearch.asp,
which comes out different depending on the UA string.
Here is output from fc:

Comparing files basicsearch.asp.mozilla and basicsearch.asp.netscape
****** basicsearch.asp.mozilla
    13:  <!--
    14:  var bName = "NS4";                                                    
 //browser name
    15:  var showMode = "true";                          //search mode state
****** basicsearch.asp.netscape
    13:  <!--
    14:  var bName = "NS6";                                                    
 //browser name
    15:  var showMode = "true";                          //search mode state
******

****** basicsearch.asp.mozilla
    16:  var defaultMode = "1";                          //search mode
    17:  var browserV = "5.0 ";                                         
//browser version
    18:  var noSrchTerm = "0";
****** basicsearch.asp.netscape
    16:  var defaultMode = "1";                          //search mode
    17:  var browserV = "6.2";                                          
//browser version
    18:  var noSrchTerm = "0";
******

****** basicsearch.asp.mozilla
   111:          
   112:                  <ILAYER ID="divHelp1"><LAYER ID="divHelp2"
HEIGHT="60px" WIDTH="650px" &{if(document.layers["divHelp1"]){LEFT=d
   113:  ocument.layers["divHelp1"].left;} else{"LEFT=0";}};
&{if(document.layers["divHelp1"]){TOP=document.layers["divHelp1"].top;} els
   114:  e{"TOP=0";}};></LAYER></ILAYER> 
   115:                          
   116:          <TD align="left" valign="top" width="27%">&nbsp;</TD>
****** basicsearch.asp.netscape
   111:          
   112:                  <div id="divHelp" name="divHelp" align="left"></div>
   113:                  
   114:          <TD align="left" valign="top" width="27%">&nbsp;</TD>
******

NOW I will get back to Ebsco.

Comment 10

[Jonadab the Unsightly One (Nathan Eady)]

Attachment: Most recent email sent to Ebsco

Here is a copy of my most recent email to Ebsco about the issue.

Comment 11

[Zach Lipton [:zach]]

ecomm

Comment 12

[Jonadab the Unsightly One (Nathan Eady)]

Attachment: Another message sent to Ebsco support, Cc to OPLIN support

Having seen no change in the situation for over two months, I contacted Ebsco 
again, summarising and reiterating everything.	I copied OPLIN support on this 

one too.

Comment 13

[Brant Gurganus]

The connection is being refused for me.

Comment 14

[Jonadab the Unsightly One (Nathan Eady)]

Brant:  what connection is being refused?  

URL has become obsolete, due to some restructuring of the EbscoHost site.
New login URL is here:
http://search.epnet.com/login.asp

The estimate I was given by an Ebsco Representative on 20 February
was 2-4 months, since a coding change would be required.  (Not sure
why a coding change is required, other than to change a string from
"Netscape" to "Gecko", but I'm not familiar with their source base.)

Anyway, we're coming up on four months in two days now, so I've 
retested this, and so far the situation has not changed.  When
the four-month estimate completely passes later this week, I'll
plan to recontact Ebsco and see how they're getting along.  I 
want to be patient here...  

Comment 15

[Jonadab the Unsightly One (Nathan Eady)]

Attachment: Another message sent to an Ebsco representative.

He said to check back with him if I wanted to know "the status",
so I checked back with him.

Comment 16

[Jonadab the Unsightly One (Nathan Eady)]

Platform->All
Not sure why I missed that before; I confirmed this on an iMac months ago.  

The whole issue is the presense or absense of "Netscape" in the ua string.
No other part of the string seems to matter at all (except perhaps the
Mozilla version number, 5.x vs 4.x).  It also doesn't matter where the
string "Netscape" occurs, so long as it is there.  The vendorSub doesn't
matter either.  As near as I can tell, you can make your uastring say 
something like "Mozilla/5 NotNetscapeApproved Opera 6.0" and you'd get
the content intended for Netscape 6.x.  But with a standard Gecko UA 
string with any vendor other than Netscape (or no vendor), you get what 
appears to be legacy content intended for Netscape 4.x

Target->July.  If we're lucky.  

Comment 17

[Jonadab the Unsightly One (Nathan Eady)]

Attachment: email I received back from an Ebsco representative, stating that the problem is fixed in an upcoming release

Note that the fixed version (which I have not seen) is not live
on the Ebsco site as yet, so I am not marking this issue as 
fixed at this time.  The message does predict a timeframe that
is consistent with the current target milestone.  This is good.

Comment 18

[Jonadab the Unsightly One (Nathan Eady)]

Tested and verified working with the following UA string:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
GalionPublicLibrary/1.1

The new version is visibly different; certain GIF buttons have
been replaced with <input type="submit"> buttons.  That wasn't 
necessary for Mozilla, but in any case it works now.  Good to
have this resolved.    

Comment 19

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg