Details
-
Type:
Bug
-
Status: Closed
-
Priority:
High
-
Resolution: Fixed
-
Affects Version/s: proxy:1.0.0
-
Fix Version/s: proxy:1.0.3
-
Component/s: proxy
-
Environment:any
-
Epic Link:
-
Frequency:Occasional - May occured/be used from time to time, in specific situation
-
Account:GZL25 - PROXY02.5 - Qualification - 580952 (580952)
Description
Proxy frame decoder is lost if a client sends an request with the header Expect: 100-continue (HTTP 1.1)
When sending such request, the Content-Lenght is usually not 0, but there is no body yet. The Client is waiting for the server to send back a response with 100 Continue status, before sending the body.
In that situation, Proxy decoder and recorder are still waiting for the body, but they see a response first and are "lost". Then when the body is sent, there is no header so Proxy fails again to detect the frame.
That scenario should be supported by proxy decoder and recorder.
Pay attention that the flow may be interrupted if the server returns other than 100 Continue, such as 417 or 400 or other errors. Also, the client can decide to send the body if the server takes too much time to respond to the Expect continue.
See https://www.rfc-editor.org/rfc/rfc2616#section-8.2.3
Ideally, to be transparent to the user, such workflow should be recored in 4 messages in datahouse
1. request without body with header Expect: 100-continue
2. response with 100 Continue status
3. request body alone
4. final response.
But it may cause some troubles to datahouse-ui, especially the partial request with body only.
[ABA] If that takes too much time to adapt datahouse, we can do it the way it was supported in Proxy v7 : only 3 messages recorded
1. request rebuilt with header and body
2. response 100 continue
3. final response
Decision to discuss with management
When sending such request, the Content-Lenght is usually not 0, but there is no body yet. The Client is waiting for the server to send back a response with 100 Continue status, before sending the body.
In that situation, Proxy decoder and recorder are still waiting for the body, but they see a response first and are "lost". Then when the body is sent, there is no header so Proxy fails again to detect the frame.
That scenario should be supported by proxy decoder and recorder.
Pay attention that the flow may be interrupted if the server returns other than 100 Continue, such as 417 or 400 or other errors. Also, the client can decide to send the body if the server takes too much time to respond to the Expect continue.
See https://www.rfc-editor.org/rfc/rfc2616#section-8.2.3
Ideally, to be transparent to the user, such workflow should be recored in 4 messages in datahouse
1. request without body with header Expect: 100-continue
2. response with 100 Continue status
3. request body alone
4. final response.
But it may cause some troubles to datahouse-ui, especially the partial request with body only.
[ABA] If that takes too much time to adapt datahouse, we can do it the way it was supported in Proxy v7 : only 3 messages recorded
1. request rebuilt with header and body
2. response 100 continue
3. final response
Decision to discuss with management
