Re: nosgml options

On 23 Jan 2003, Ville Skyttä wrote:

> On Thu, 2003-01-23 at 19:11, Nigel J. Andrews wrote:
> 
> > I installed the validator locally as I was finding the W3C server typically
> > took 20s to delivery result pages to my application. However, I've found that
> > it takes about the same locally as well. Now I've verified that check runs for
> > about 2s and I've sat watching the network traffic appear about 15s after this
> > exits. So, is this a known issue?
> 
> No, I can't reproduce it locally or on validator.w3.org.  For example,
> validating <http://www.w3.org/> takes about 2-3 seconds here, using
> either a local instance or validator.w3.org.  What is your
> "application"?  Can you reproduce the delay with a browser?
> 
> > Perhaps it's the result of setting server-parsed on .html files for the
> > validator?
> 
> I don't think so, I guess validator.w3.org doesn't use that setup, but
> uses XBitHack for its .html.  And my local setup uses the server-parsed
> one.

Thanks for the replies on this and the previous message I sent about the -R
flag.

For the flag, it's not a public server but I think I'll get and install the
full 1.5 version rather the prerelease one. I'm not sure about this
introduction of new features at that stage of development but I'm all for
security fixes. I also meant not worth me generating and submitting a patch
removing the -R flag, I didn't know about the security fix patch at the time.

However, to the subject of this email...I have sorted this problem although I
still do not understand the reasons.

My little application is in perl. It sends the http request to the validator
and then reads the response using the standard perl construct of
while (<fh>) ... The first returned line was processed after 2 seconds but the
loop only finished 16 seconds after that. Adding the header Connection: close
to the request caused the loop to terminate after only 2-3 seconds.

I am still confused because of the burst in network traffic associated with the
connect I was seeing after the large delay. This to me implies the perl client
was somehow causing the server system to not transmit all the data until some
timeout expired. I guess if I look in the server config I'll find a timeout
for persistent connections of something like 15 seconds but why would the
server not transmit the data until the connection was closed? 

Anyway, as I say I have a solution if not the understanding.

-- 
Nigel J. Andrews

Received on Thursday, 23 January 2003 18:07:54 UTC