URL problem. ("feature")?

General JUCE discussion
1

JUCE 1.37

Just a heads-up. This one had me foxed for a while.
I noticed my client code was pumping lots of extra records into my server-side db, even though i was sure i was submitting only once.
Something like this:

	URL u(m_ServerUrl + T("/cgi-bin/getwork.cgi"));
	
	InputStream *i = u.createPostInputStream("function=get_work");

	m_Name = i->readNextLine();
	m_JobId = i->readNextLine();
	m_Data = i->readNextLine().getHexValue64();
	m_Key1 = i->readNextLine().getHexValue32();
	m_Key2Start = i->readNextLine().getHexValue32();
	m_Key2End = i->readNextLine().getHexValue32();
	m_Key3 = i->readNextLine().getHexValue32();

The cgi script sends back plaintext, but if the lines are only terminated with “\n” readNextLine() reads the entire content and re-submits the request for each subsequent call! If I make the server send back “\r\n” as a line terminator, everything is hunky-dory.

I’m not sure which is the “correct” way to send back line-endings, but most of the scripts i’ve seen only use “\n”.

2

This will just be because an internet input stream can’t reposition itself, so when the readNextLine() does a seek(), it’ll have to re-start the stream.

The best way to fix this is to use a BufferedInputStream to wrap your http stream, which will read large chunks at once and keep them in memory to avoid re-reading from the source.

3

I understand what you are saying, but in that case the behaviour should be the same irrespective of the line terminator?

Sending “\r\n” to the client works 100% here - only one request is received at the server.

4

True, I’ll take a look at the readNextLine() method.

In fact what I’d probably do myself here is not bother with the stream, but use URL::readEntireTextStream and StringArray::addLines. If it’s a small amount of data, that’d be much neater and more efficient.

5

[quote=“jules”]

In fact what I’d probably do myself here is not bother with the stream, but use URL::readEntireTextStream and StringArray::addLines. If it’s a small amount of data, that’d be much neater and more efficient.[/quote]

Of course. Thanks for the tip :smiley: