Kbase 18963: Using telnet and HTTP to debug WebSpeed issues
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  7/12/1999 |
|
SUMMARY:
This solution applies to WebSpeed 1.X and later.
Debugging WebSpeed issues can be difficult, especially when you
have problems with cookies, or errors that are being interpreted
by browsers as headers. Typically, browsers will hide the HTTP
header information from you, including cookie information. This
kbase gives a simple method to view what is actually being
received by a browser.
EXPLANATION:
You can use telnet to imitate a browser. The way a browser
works is by opening a TCP socket to a web server host machine.
The web server typically listens for incoming connections on
port 80, although this can be changed. Once the connection is
established, the web browser sends some specific text to the
web server. This is HTTP. This instructs the web server what
information the browser is requesting. This is followed by a
blank line to indicate the end of the HTTP information. The web
server will then respond with the information we requested
(hopefully), back along this connection.
We can use telnet to mimic this information, provided we know
the HTTP syntax.
- using a UNIX (or DOS-based) telnet program, type in
telnet hostname 80
This opens a socket to port 80 on hostname. If the web server
is on a different port, type this instead of 80
- you may get some garbage information come up, about escape
characters. Ignore this, the connection will be terminated once
the request has finished.
- Type in
GET <url> HTTP/1.0
This is HTTP syntax: it is making a GET request for a specific
URL, using protocol HTTP 1.0 (version 1.0 of HTTP).
- press enter twice, so there is a blank line after this GET.
- the web server will respond with the requested information.
- the connection will terminate immediately. This is expected.
For example, we can see what happens when you connect to WebSpeed
Workshop 2.1 (from unix). The URL can be a relative URL once we
connect to the server via telnet. The URL we are using is
/scripts/cgiip.exe/WService=sports/workshop :
fred$ telnet WSserver 80
Trying 133.14.128.218...
Connected to WSserver
Escape character is '^]'.
GET /scripts/cgiip.exe/WService=sports/workshop HTTP/1.0
HTTP/1.0 200 OK
Server: Microsoft-PWS/2.0
Date: Thu, 01 Jul 1999 22:40:16 GMT
Content-Type: text/html
<!-- Generated by WebSpeed - http://www.WebSpeed.com/ -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>WebSpeed Workshop</TITLE>
<META NAME = "Generator" CONTENT = "WebSpeed [workshop]">
<META NAME = "Author" CONTENT = "Wm.T.Wood">
</HEAD>
<FRAMESET COLS="152,*">
<FRAMESET ROWS="92,*">
<FRAME NAME="WS_header" SRC="workshop.w?html=MainMenu" SCROLLING=no
FRAMEBORDER=yes MARGINHEIGHT=0 MARGINWIDTH=0>
<FRAME NAME="WS_index" SRC="webtools/index.w?html=AboutIndex"
FRAMEBORDER=yes MARGINHEIGHT=3 MARGINWIDTH=3>
</FRAMESET>
<FRAME NAME="WS_main" SRC="/webspeed/workshop/welcome.html"
FRAMEBORDER=yes MARGINHEIGHT=5 MARGINWIDTH=10>
</FRAMESET>
<NOFRAME>
<H1>WebSpeed Workshop</H1>
This page can be displayed with a frame enabled browser.
</NOFRAME>
</HTML>
Connection closed by foreign host.
We can see here the HTTP headers sent back by the web server. We
can see the web server being used, the document type and date.
Any cookie information will be displayed in this HTTP header
information as well.
This is a simple method of checking the HTTP headers. It is fairly
limited, as you will have to know how to use HTTP properly to be
able to debug large applications, with POST requests as well.
References To Written Documentation:
HTTP specs are available from http://www.w3c.org/