Forums Feature Suggestions /sockpeek

Can we get a command that will peek into the sock-read buffer and return the buffered data without removing the data from the sockread buffer?

I'm currently working on an httpd and at times I need to see "whats next" before deciding what to do with the current data.

For example, HTTP headers can be folded(split into multiple lines) by following a linebreak(\r\n) with whitespace characters(tab or space):

<code>Header-Name: This is[\r\n]
a valid header[\r\n]</code>

After reading the header with /sockread -n &bvar, I'd like to be able to 'peek' into the read buffer to see if its followed by a whitespace character

I'm not a big fan of this suggestion, this is typically something you should be scripting yourself, just stored the line read, read the next line and then deal with both lines.
This would not solve the problem of having to store state for when the data is not immediately available (sockreading multiple time in the same event)
It would mean mIRC would have to read the line from winsock and temp store it for you, effectively meaning that /sockread would have to check if there is something to read from a different buffer before processing the rq buffer, it would add extra processing for socket for everyone's code when you should be the one temp storing the data you want, this would just slow down the processing of socket in general, and while it's not so bad of suggestion in itself, I don't think a lot of people would actually use this, sorry I just hate this idea!
And would it fill $sockbr and $sockerr etc? There are more things to figure out than just adding a new command here, I think.

In the meantime I'm sure you know about this but your concrete example is trivial to solve:

This is not how winsock works. You provide winsock with a buffer pointer when the socket descripter is created, and as data comes in, winsock adds the data to the buffer. There is no copying from a winsock buffer into an application buffer or such.

Now lets says that above is incorrect and you provide a buffer with each read. You have failed to account for mIRC already keeping a buffer. For example if there isn't a $crlf in the buffer, '/sockread %data' keeps data in the buffer even though mIRC would have had to read data from winsock to check for $crlf in the first place

Yes, to both. The only difference between the suggested /sockpeek and /sockread is that after mIRC extracts the 'read bytes' from the buffer, it would not remove those bytes from the buffer

mIRC already keeping a buffer is what I'm talking about, I doubt the 'buffer pointer' filled by winsock is the same buffer that 'we' read from but I don't know exactly about the implementation there. Like I said it's not a bad idea in itself but that may just add complication to the current implementation for something that is not needed, that is, you can script it. In the meantime there are dozen of suggestions which can't be done by scripting, though, certainly, it's not what should matter or what should prevent you from making suggestions.