Please can you submit a CLA?

https://openssl-library.org/policies/cla/

Please can you submit a CLA?

https://openssl-library.org/policies/cla/

Yup emailed it this morning, still pending approval c:

Thank you everyone for your interest and time in reading through my code! I have implemented changes from most of the comments and I have responded to the rest. I would greatly appreciate it if you could kindly review the PR again for further improvements c:

I'm wondering what the behavior of using SSL_MODE_ENABLE_PARTIAL_WRITE should be with this. Should we support this? If we support it, is it then up to the application to figure out which iovecs to remove in the next call, and how to update the data pointers in the iovec?

So Linux has a pwritev(), that supports an additional offset. We should consider that for the combination with SSL_MODE_ENABLE_PARTIAL_WRITE.

So Linux has a pwritev(), that supports an additional offset. We should consider that for the combination with SSL_MODE_ENABLE_PARTIAL_WRITE.

Sorry wanted to clarify, do you mean SSL_MODE_ENABLE_PARTIAL_WRITE or SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER? I thought SSL_MODE_ENABLE_PARTIAL_WRITE is currently supported for OSSL_IOVECs by storing an offset variable that keeps track of how much we have sent so far? Could I trouble you to expand a little bit on what is the issue we are trying to solve? Thanks in advance

In case of SSL_MODE_ENABLE_PARTIAL_WRITE, you don't have to call it with data that was already processed, like in a call to write(). *written will contain how much data has been processed and doesn't need to be passed again when called again. When that flag is not passed, you need to pass exactly the same data.

Since it's in an iovec, you might want to pass the same iovec again, but say how much of the data needs to be skipped. Otherwise, you will need to move data around, or at least update the pointer. But if you're updating the pointer, you might need to have a second copy of the pointer so you can delete it. It's probably easier that we can pass the value of *written back on the next call, or an adjusted version of that if we can remove 1 or more iovecs.

@kroeckx I see what you mean now. I was under the impression that removing written data is the responsibility of the caller, I refer to the description of SSL_MODE_ENABLE_PARTIAL_WRITE from SSL_write.pod:

When this flag is set the write functions will also return with success when a partial write has been successfully completed. In this case the write function operation is considered completed. The bytes are sent and a new write call with a new buffer (with the already sent bytes removed) must be started.

However, you make a good point that this can be quite troublesome. Can I clarify that you propose that if the flag is set, we use the value stored inside *written to indicate that the first *written bytes will be skipped during the write procedure?

@kroeckx I have updated the SSL_writev such that if the flag is set, we use the value stored inside *written to indicate that the first *written bytes will be skipped during the write procedure. Let me know if this was what you meant. Thank you

*written is an output. From your message, I think you want to use it as input too. I would expect a new offset variable that is input only.

I was thinking that instead of using two arguments, the *written can first store the offset, but once the method returns, *written will return the new total amount that has been successfully sent. This way, the user can call SSL_writev repeatedly by passing the same *written variable.

Using a separate argument for offset works as well. however, in this case when the SSL_writev returns, should *written contain the amount of bytes newly sent or contain the total number of bytes sent from the beginning of the iovec?

I was thinking that instead of using two arguments,

As a general pattern, we have (mostly) moved away from having an in/out parameter for this sort of thing as much as possible so it is clear what is going on in the API calls when looking at the code.

@kroeckx @t-j-h Thank you for both of your input. I have updated the SSL_writev to accept an additional argument, offset.

@mattcaswell @kroeckx @t-j-h @t8m Hi everyone, thank you for the feedback that you all have provided. I was hoping to get a status update for this PR. If there are any other requested improvements, please let me know.