[BUG] fetch documentation doesn't work

Wed Apr 17 15:34:11 UTC 2002

With the recent discussion about documentation in Squeak, I just had 
to try the "fetch documentation" menu item from the Browser. And it 
blew up again, just like it has every time I've tried it. I get a 
Syntax Error that reads across the top: "UndefinedObject  as yet 
unclassified  Nothing".  Below it reads "Nothing more expected -><". 
This might be a bit confusing for newbies...

It seems to me that this should either be removed, or fixed.

The main problem is that the server that is being contacted doesn't 
have any documentation on it (at least not where it's being looked 
for).

This is aggravated by a lack of error detection, and further 
aggravated by a lack of exception handling.

What happens in Browser>>fetchClassDocPane is:

	DocLibrary external fetchDocSel: '' class: self selectedClassName

which is trying to get in touch with a URL that starts with:
'http://squeak.cs.uiuc.edu/Squeak2.0/docpane/'

What's happening is that the server is responding:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /Squeak2.0/docpane/TransformationMorph.0.sp was not 
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.6 Server at squeak.cs.uiuc.edu Port 80</ADDRESS>
</BODY></HTML>

and this is being fed to ReadWriteStream>>fileInObjectAndCode. Which 
can't interpret it as valid Smalltalk.

Interestingly, this string is being returned from 
HTTPSocket>>httpGetNoError:args:accept: which looks like this:

httpGetNoError: url args: args accept: mimeType
	"Return the exact contents of a web file.  Do better error checking.  
Asks for the given MIME type.  To fetch raw data, you can use the 
MIMI type 'application/octet-stream'.  If mimeType is nil, use 
'text/html'.  The parsed header is saved. Use a proxy server if one 
has been registered."
	| document data |
	document _ self httpGetDocument: url  args: args  accept: mimeType.
	(document isKindOf: String) ifTrue: [
		"strings indicate errors"
		^ document ].
	data _ document content.
	(data beginsWith: '<HTML><HEAD>' , (String with: Character linefeed) 
, '<TITLE>4')
		ifTrue: ["an error message  404 File not found"
				^ data copyFrom: 21 to: data size-16].	

	^ (RWBinaryOrTextStream with: data) reset

The parsing for an error message here is a bit fragile, to say the 
least. When the format of the error message from the server changed a 
little bit, our method broke.

Why isn't the HTTP response code being used? Well, we had it in 
HTTPSocket class>>httpGetDocument:args:accept:request: (in fact we'd 
already parsed the headers). The problem is that this method returns 
one of two things: a HTTPDocument if everything was good, or a string 
of some sort if we had a problem. This throws away the headers, 
response code, etc., and requires users to parse the returned string.

It seems to me that what we need here is a HTTPResponse that can store 
response code, headers, and content.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE