Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1093784 - The Expect header is ignored
Summary: The Expect header is ignored
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.3.0
Hardware: All
OS: Linux
Target Milestone: ---
: 3.5.0
Assignee: Juan Hernández
QA Contact: Antonin Pagac
Whiteboard: infra
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
Reported: 2014-05-02 16:07 UTC by Anand Nande
Modified: 2018-12-05 18:28 UTC (History)
13 users (show)

Fixed In Version: ovirt-3.5.0-alpha2
Doc Type: Bug Fix
Doc Text:
Previously, requests sent via the REST API containing the Expect header did not have the intended effect. This meant that requests that used the Expect header to indicate that they require synchronous execution were actually executed in an asynchronous fashion. This behavior was expected, because the Apache web server rejects a request with an Expect header if it contains any value other than '100-continue'; to mitigate this, the Red Hat Enterprise Virtualization Manager explicitly removed the header from every request. Now, the Manager has been modified to accept an alternative X-Ovirt-Expect header, which has the same values and semantics as the Expect header. To ensure that this header has the desired effect, users must send both the Expect and the X-Ovirt-Expect header with the same value. Developers of client software are encouraged to modify their applications to send both headers with the same value, so that requests will work with previous and upcoming versions of the Manager.
Clone Of:
Last Closed: 2015-02-11 18:01:14 UTC
oVirt Team: Infra
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 27930 master MERGED restapi: Accept Expect and X-Ovirt-Expect Never
oVirt gerrit 27935 None None None Never
oVirt gerrit 27937 None None None Never

Description Anand Nande 2014-05-02 16:07:19 UTC
When using perl scripts using the REST-api to manipulate VMs. One can
notice the following difference in behaviour between versions 3.2 and 3.3

To create a VM one uses POST to put the xml payload to URL /api/vms. 
If there is a need for it to be synchronous, then add "expect 201-created" header.

In 3.2 this POST call takes *11 seconds* and the resulting xml contains
status "down", meaning the custom_software can "start" the VM.

In 3.3 this POST call takes 1 second and the resulting xml contains
status "locked" and an additional creation_status "pending", meaning
that one cannot "start" the VM.

In the release 3.3 notes there is no mention of this change.

Which API calls are affected in RHEV-3.3 as compared to 3.2? This needs to be documented.

Comment 2 Juan Hernández 2014-05-05 12:24:59 UTC
I think that the problem is that in we actually remove the Expect header from requests, so whatever the caller sends is completely ignored.

We explicitly remove it, with the following web server configuration in /etc/httpd/conf.d/z-ovirt-engine.conf:

  <IfModule headers_module>
    RequestHeader unset Expect early

We do this because the web server doesn't support the Expect header unless it has the 100-continue value. The value that we use to specify blocking operation is 201-created, and that causes the following web server response:

  <title>417 Expectation Failed</title>
  <h1>Expectation Failed</h1>
  <p>The expectation given in the Expect request-header
  field could not be met by this server.
  The client sent<pre>
      Expect: 201-created
  </p><p>Only the 100-continue expectation is supported.</p>

This should happen in 3.2 as well, unless they were connecting to the application server directly, not via the web server. Can you confirm this? If this is the case then I would suggest, as a temporary workaround, to do the same in 3.3.

Comment 3 Juan Hernández 2014-05-05 13:24:48 UTC
I just noticed that the application server is also swallowing the Expect header, so the workaround proposed in comment 2 won't work. I'm checking if this changed in a recent version of the application server.

Comment 4 Juan Hernández 2014-05-05 14:11:10 UTC
I have to correct myself, I didn't test this correctly. The expect header is not swallowed by the application server. So the workaround described in comment 2 (connect directly to the application server) does work. Please ask the customer to try it, and report the results.

Comment 5 Juan Hernández 2014-05-20 12:25:23 UTC
The proposed patch changes the RESTAPI so that it will accept the old Expect header and a new X-Ovirt-Expect one. Both have the same meaning, but the new one isn't rejected by the web server. To preserve backwards compatibility users are encouraged to send both headers, with the same value, for example:

  POST /ovirt-engine/api/vms HTTP/1.1
  Expect: 201-created
  X-Ovirt-Expect: 201-created

The first will be removed by the web server, but the second will reach the application server and have the expected effect.

Comment 6 Antonin Pagac 2014-09-04 14:35:42 UTC

I tried to create a vm, add a disk to it (so the operation would take significant time) and then start it, all this in a script using REST API. Without using headers '-H "Expect: 201-created" -H "X-Ovirt-Expect: 201-created"' the operation failed. When I used the headers, operation took longer to finish and succeeded.

oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6

Comment 8 errata-xmlrpc 2015-02-11 18:01:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.