| bd269ebc | 26-Apr-2017 |
Markus Armbruster <armbru@redhat.com> |
sockets: Limit SocketAddressLegacy to external interfaces
SocketAddressLegacy is a simple union, and simple unions are awkward:
they have their variant members wrapped in a "data" object on the
wire
sockets: Limit SocketAddressLegacy to external interfaces
SocketAddressLegacy is a simple union, and simple unions are awkward:
they have their variant members wrapped in a "data" object on the
wire, and require additional indirections in C. SocketAddress is the
equivalent flat union. Convert all users of SocketAddressLegacy to
SocketAddress, except for existing external interfaces.
See also commit fce5d53..9445673 and 85a82e8..c5f1ae3.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1493192202-3184-7-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[Minor editing accident fixed, commit message and a comment tweaked]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
show more ...
|
| b8a68728 | 03-Apr-2017 |
Daniel P. Berrange <berrange@redhat.com> |
io: fix FD socket handling in DNS lookup
The qio_dns_resolver_lookup_sync() method is required to be a no-op
for socket kinds that don't require name resolution. Thus the KIND_FD
handling should not
io: fix FD socket handling in DNS lookup
The qio_dns_resolver_lookup_sync() method is required to be a no-op
for socket kinds that don't require name resolution. Thus the KIND_FD
handling should not return an error.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 07e95cd5 | 28-Feb-2017 |
Daniel P. Berrange <berrange@redhat.com> |
io: fully parse & validate HTTP headers for websocket protocol handshake
The current websockets protocol handshake code is very relaxed, just
doing crude string searching across the HTTP header data
io: fully parse & validate HTTP headers for websocket protocol handshake
The current websockets protocol handshake code is very relaxed, just
doing crude string searching across the HTTP header data. This causes
it to both reject valid connections and fail to reject invalid
connections. For example, according to the RFC 6455 it:
- MUST reject any method other than "GET"
- MUST reject any HTTP version less than "HTTP/1.1"
- MUST reject Connection header without "Upgrade" listed
- MUST reject Upgrade header which is not 'websocket'
- MUST reject missing Host header
- MUST treat HTTP header names as case insensitive
To do all this validation correctly requires that we fully parse the
HTTP headers, populating a data structure containing the header
fields.
After this change, we also reject any path other than '/'
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| c4c497d2 | 13-Feb-2017 |
Paolo Bonzini <pbonzini@redhat.com> |
io: make qio_channel_yield aware of AioContexts
Support separate coroutines for reading and writing, and place the
read/write handlers on the AioContext that the QIOChannel is registered
with.
Revi
io: make qio_channel_yield aware of AioContexts
Support separate coroutines for reading and writing, and place the
read/write handlers on the AioContext that the QIOChannel is registered
with.
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 20170213135235.12274-7-pbonzini@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| c1b412f1 | 19-Jul-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: introduce a DNS resolver API
Currently DNS resolution is done automatically as part
of the creation of a QIOChannelSocket object instance.
This works ok for network clients where you just end
up
io: introduce a DNS resolver API
Currently DNS resolution is done automatically as part
of the creation of a QIOChannelSocket object instance.
This works ok for network clients where you just end
up a single network socket, but for servers, the results
of DNS resolution may require creation of multiple
sockets.
Introducing a DNS resolver API allows DNS resolution
to be separated from the socket object creation. This
will make it practical to create multiple QIOChannelSocket
instances for servers.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 59de517d | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: remove Error parameter from QIOTask thread worker
Now that task objects have a directly associated error,
there's no need for an an Error **errp parameter to
the QIOTask thread worker function.
io: remove Error parameter from QIOTask thread worker
Now that task objects have a directly associated error,
there's no need for an an Error **errp parameter to
the QIOTask thread worker function. It already has a
QIOTask object, so can directly set the error on it.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 60e705c5 | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: change the QIOTask callback signature
Currently the QIOTaskFunc signature takes an Object * for
the source, and an Error * for any error. We also need to
be able to provide a result pointer. Rat
io: change the QIOTask callback signature
Currently the QIOTaskFunc signature takes an Object * for
the source, and an Error * for any error. We also need to
be able to provide a result pointer. Rather than continue
to add parameters to QIOTaskFunc, remove the existing
ones and simply pass the QIOTask object instead. This
has methods to access all the other data items required
in the callback impl.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 1a447e4f | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to associate an error with a task
Currently when a task fails, the error is never explicitly
associated with the task object, it is just passed along
through the completion callback.
io: add ability to associate an error with a task
Currently when a task fails, the error is never explicitly
associated with the task object, it is just passed along
through the completion callback. This adds the ability to
explicitly associate an error with the task.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 52dd99e8 | 11-Aug-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to associate an opaque "result" with with a task
Currently there is no data associated with a successful
task completion. This adds an opaque pointer to the task
to store an arbitrar
io: add ability to associate an opaque "result" with with a task
Currently there is no data associated with a successful
task completion. This adds an opaque pointer to the task
to store an arbitrary result.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| 20f4aa26 | 30-Sep-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: add ability to set a name for IO channels
The GSource object has ability to have a name, which is useful
when debugging performance problems with the mainloop event
callbacks that take too long.
io: add ability to set a name for IO channels
The GSource object has ability to have a name, which is useful
when debugging performance problems with the mainloop event
callbacks that take too long. By associating a name with a
QIOChannel object, we can then set the name on any GSource
associated with the channel.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| bf535208 | 26-Oct-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: set LISTEN flag explicitly for listen sockets
The SO_ACCEPTCONN ioctl is not portable across OS, with
some BSD versions and OS-X not supporting it. There is
no viable alternative to this, so ins
io: set LISTEN flag explicitly for listen sockets
The SO_ACCEPTCONN ioctl is not portable across OS, with
some BSD versions and OS-X not supporting it. There is
no viable alternative to this, so instead just set the
feature explicitly when creating a listener socket.
The current users of qio_channel_socket_new_fd() won't
ever be given a listening socket, so there's no problem
with no auto-detecting it in this scenario
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| d8d3c7cc | 29-Sep-2016 |
Felipe Franciosi <felipe@nutanix.com> |
io: Introduce a qio_channel_set_feature() helper
Testing QIOChannel feature support can be done with a helper called
qio_channel_has_feature(). Setting feature support, however, was
done manually wi
io: Introduce a qio_channel_set_feature() helper
Testing QIOChannel feature support can be done with a helper called
qio_channel_has_feature(). Setting feature support, however, was
done manually with a logical OR. This patch introduces a new helper
called qio_channel_set_feature() and makes use of it where applicable.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
| e413ae0c | 29-Sep-2016 |
Felipe Franciosi <felipe@nutanix.com> |
io: Use qio_channel_has_feature() where applicable
Parts of the code have been testing QIOChannel features directly with a
logical AND. This patch makes it all consistent by using the
qio_channel_ha
io: Use qio_channel_has_feature() where applicable
Parts of the code have been testing QIOChannel features directly with a
logical AND. This patch makes it all consistent by using the
qio_channel_has_feature() function to test if a feature is present.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|