Closed
Bug 206031
Opened 22 years ago
Closed 22 years ago
test client not interactive on windows
Categories
(NSS :: Tools, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
3.9
People
(Reporter: nelson, Assigned: nelson)
References
Details
Attachments
(1 file)
7.13 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
On Unix systems, tstclnt acts like a simple telnet client, allowing interactive
use from the keyboard. On windows, it doesn't. On Windows, it reads all
input from stdin before looking for any response from the server. This is
because PR_Poll doesn't work with stdin on Windows.
tstclnt should be interactive on Windows, too.
Patch forthcoming.
Assignee | ||
Comment 2•22 years ago
|
||
This patch uses a socket pair and a separate thread to simulate a pollable
stdin.
The new thread reads from stdin and writes to one socket of the pair.
The main program thread reads from (and polls) the other socket of the pair,
as a substitute for stdin.
Please review.
Comment 3•22 years ago
|
||
Comment on attachment 123574 [details] [diff] [review]
patch simulates pollable stdin.
r=wtc. Some suggested changes.
1. Use WIN32 or _WINDOWS consistently.
2. Use <fcntl.h> and <io.h> instead of "fcntl.h" and "io.h"
because they are standard header files.
3. The -f option is not used with your patch. Should we
remove it?
Attachment #123574 -
Flags: review+
Assignee | ||
Comment 4•22 years ago
|
||
I tried removing the -f option and found that the ssl.sh test script uses the
-f option. We could remove it from that script, but I wonder if any third
parties also would be affected by removing it.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 5•22 years ago
|
||
Comment on attachment 123574 [details] [diff] [review]
patch simulates pollable stdin.
Nelson, I'm having second thoughts about the part of
this patch that set stdin in binary mode. tstclnt
always reads text input, so its stdin should remain
in text mode, right?
Assignee | ||
Comment 6•22 years ago
|
||
When used interactively, stdin will typically be just text.
But when simulating an https POST request, the content can be binary.
In that case, the header includes an explicit length of the data that
follows.
The real reason for using binary mode, however, is because http requires
that header lines end in \r\n. In "text" mode, the \r's will be stripped.
I could try to add them back before copying text to the socketpair, e.g.
calling fgets, and replacing the line endings before writing to the socket.
But this has problems for the aforementioned binary input case.
Perhaps we need something like an "isatty" test for windows. With stdin
in binary mode, ^Z is no longer recognized as meaning END_OF_FILE. :-(
Here's another thought/question. Can PR_NewTCPSocketPair fail on windows
client systems that are moderately loaded? I seem to recall that Windows
attempts to limint the number of listen sockets allowed, except on Windows
server OSes. With the new call to PR_NewTCPSocketPair, tstclnt requires
server socket permissions on Windows systems that run firewall software
that only permits the use of listen sockets to approved programs.
Is there another way to simulated a pollable stdin with NSPR without using
a TCP listen socket?
Comment 7•22 years ago
|
||
Windows limits the backlog queue size of a listening socket
on a non-server flavor of Windows. I don't know of any
limit that Windows imposes on the number of listen sockets
allowed, but it is possible.
PR_NewTCPSocketPair may trigger a warning on a system running
a personal firewall. There is no way to simulate a pollable
stdin with NSPR without using a TCP listen socket. On Windows,
select() only operates on sockets.
You need to log in
before you can comment on or make changes to this bug.
Description
•