Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow images on subsequent (chaining) requests #2184

Closed
1 task
moono opened this issue Nov 24, 2023 · 3 comments
Closed
1 task

Flow images on subsequent (chaining) requests #2184

moono opened this issue Nov 24, 2023 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@moono
Copy link

moono commented Nov 24, 2023

Problem to solve

Hi, I would like to test APIs with hurl. My API expects inputs be multipart-formdata, while responses image as output in bytes.

Lets say I have two APIs,

  • API a
POST http://{{host}}:{{port}}/api/a
[MultipartFormData]
image: file,input_image.png;
canny: {"low": 100, "high": 200}

HTTP 200
  • API b
POST http://{{host}}:{{port}}/api/b
[MultipartFormData]
image: file,output_a.png;
resize: {"width": 512, "height": 512}

HTTP 200

If I run both requests separately, it work perfectly fine. (using --output option on command line to save first response's output as image file and then use that image file as input to second request)

But I want to use output of first request to be input of second request --> chaining request.
I tried capturing first response as bytes and use that variable to second request with no lock.

# below fails ...

# step 01
POST http://{{host}}:{{port}}/api/a
[MultipartFormData]
image: file,input_image.png;
canny: {"low": 100, "high": 200}

HTTP 200
[Captures]
step_01_out: bytes

# step 02
POST http://{{host}}:{{port}}/api/b
[MultipartFormData]
image: {{step_01_out}}
resize: {"width": 512, "height": 512}

HTTP 200

Error message

test.hurl: Running [1/1]
error: Unrenderable variable
  --> step_01.hurl:18:18
   |
18 | image: {{step_01_out}}
   |          ^^^^^^^^^^^ variable <step_01_out> with value hex, 89504e470d0a1a ... 426082; can not be rendered
   |

test.hurl: Failure (1 request(s) in 5420 ms)
--------------------------------------------------------------------------------
Executed files:  1
Succeeded files: 0 (0.0%)
Failed files:    1 (100.0%)
Duration:        5421 ms

So it would be nice if it can send bytes between chaining requests

or if this use case already possible, please point me to right direction...

Proposal

[Capture] the output bytes as input to next request

Additional context and resources

  • N/A

Tasks to complete

  • ...
@moono moono added the enhancement New feature or request label Nov 24, 2023
@jcamiel
Copy link
Collaborator

jcamiel commented Nov 24, 2023

Hi @moono

With #1326 we're going to add the possibility of write a specific response to file. This will be possible per request thanks to Options:

# step 01
POST http://{{host}}:{{port}}/api/a
[Options]
output: output_image.png
[MultipartFormData]
image: file,input_image.png;
canny: {"low": 100, "high": 200}
HTTP 200

# step 02
POST http://{{host}}:{{port}}/api/b
[MultipartFormData]
image: file,output_image.png
resize: {"width": 512, "height": 512}

This may not be the more optimal solution for your use case (there will be a temporary write on disk) but it can solves it.

I'm working on it, I just have some preliminary work to do before. You can subscribe to #1326 notifications to get the advancement on it!

@moono
Copy link
Author

moono commented Nov 24, 2023

oh. Thank you so much~~!!
I'll subscribe the issue for later use. 😀

@jcamiel
Copy link
Collaborator

jcamiel commented Dec 3, 2023

Fixed by #2216

@jcamiel jcamiel closed this as completed Dec 3, 2023
@jcamiel jcamiel added this to the 4.2.0 milestone Dec 26, 2023
@jcamiel jcamiel linked a pull request Dec 26, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants