Bug 1093784

Summary:	The Expect header is ignored
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Anand Nande <anande>
Component:	ovirt-engine-restapi	Assignee:	Juan Hernández <juan.hernandez>
Status:	CLOSED ERRATA	QA Contact:	Antonin Pagac <apagac>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	aberezin, anande, bazulay, iheim, juan.hernandez, lbopf, lpeer, oramraz, pstehlik, rbalakri, Rhev-m-bugs, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	All
OS:	Linux
Whiteboard:	infra
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-11 18:01:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1142923, 1156165

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
of RHEVM.

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
  </IfModule>

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:

  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
  <html><head>
  <title>417 Expectation Failed</title>
  </head><body>
  <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
  </pre>
  </p><p>Only the 100-continue expectation is supported.</p>
  </body></html>

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

Verified.

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.

https://rhn.redhat.com/errata/RHSA-2015-0158.html