Skip to content

Displaying binary responses in the command line client. #2049

Closed

Description

@lovelydinosaur

Using the command line client to access a binary URL...

$ httpx https://cataas.com/cat
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Thu, 27 Jan 2022 10:41:25 GMT
Content-Type: image/jpeg
Content-Length: 35300
Connection: keep-alive
Access-Control-Allow-Origin: *
'�C�.�h�&�.\)��;՗s�-l�m/gN�<Ws��F...

This behaviour isn't really ideal. The HTTP response is giving us enough information in the Content-Type to indicate that the response is binary, not text, so we could be doing better than this.

I'd much prefer for us to have better handling for this kind of case.

For example...

$ httpx https://cataas.com/cat
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Thu, 27 Jan 2022 10:41:25 GMT
Content-Type: image/jpeg
Content-Length: 35300
Connection: keep-alive
Access-Control-Allow-Origin: *

<35300 bytes of binary data>

Or...

$ httpx https://cataas.com/cat
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Thu, 27 Jan 2022 10:41:25 GMT
Content-Type: image/jpeg
Content-Length: 35300
Connection: keep-alive
Access-Control-Allow-Origin: *

<35300 bytes of binary data>
00000000:  ff d8 ff e0 00 10 4a 46  49 46 00 01-01 01 00 48  ......JF IF.....H
00000010:  00 48 00 00 ff db 00 43  00 08 06 06 07 06 05 08  .H.....C ........
00000020:  07 07 07 09 09 08 0a 0c  14 0d 0c 0b 0b 0c 19 12  ........ ........
00000030:  13 0f 14 1d 1a 1f 1e 1d  1a 1c 1c 20 24 2e 27 20  ........ ....$.'.
00000040:  22 2c 23 1c 1c 28 37 29  2c 30 31 34 34 34 1f 27  ",#..(7) ,01444.'
00000050:  39 3d 38 32 3c 2e 33 34  32 ff db 00 43 01 09 09  9=82<.34 2...C...
00000060:  09 0c 0b 0c 18 0d 0d 18  32 21 1c 21 32 32 32 32  ........ 2!.!2222
00000070:  32 32 32 32 32 32 32 32  32 32 32 32 32 32 32 32  22222222 22222222
00000080:  32 32 32 32 32 32 32 32  32 32 32 32 32 32 32 32  22222222 22222222
00000090:  32 32 32 32 32 32 32 32  32 32 32 32 32 32 ff c0  22222222 222222..

I've not thought through what flags we'd want for controlling this display, but it seems like an obvious improvement for us to make, and I'm sure we could do a very nice job of how it's displayed with rich.

Activity

  1. lovelydinosaur commented on Jan 27, 2022

    @lovelydinosaur
    MemberAuthor

    Jotting down a couple of possibly useful resources...

  2. waterfountain1996 commented on Feb 9, 2022

    @waterfountain1996
    Contributor

    I've played around with it and I found that larger responses will take unreasonable amount of time to print (600kb takes ~20s on my machine). What would you suggest as a way around that? As for the flags, I think we could borrow the idea from curl, where it will not print the response unless output file is specified with --output flag.

  3. lovelydinosaur commented on Feb 9, 2022

    @lovelydinosaur
    MemberAuthor

    I gave the hexdump style a try, and while I thought it was neat, there's not really any way I'd actually be using it in depth. At least not as my default behaviour.

    I think a good enough pass at this point would simply be to do the following for binary content...

    $ httpx https://cataas.com/cat
    HTTP/1.1 200 OK
    Server: nginx/1.12.2
    Date: Thu, 27 Jan 2022 10:41:25 GMT
    Content-Type: image/jpeg
    Content-Length: 35300
    Connection: keep-alive
    Access-Control-Allow-Origin: *
    
    <35300 bytes of binary data>

    I think we want a switch here:

    console.print(rich.markup.escape(response.text))

    To output as text for Content-Type: text/... and output as binary otherwise.

  4. waterfountain1996 commented on Feb 9, 2022

    @waterfountain1996
    Contributor

    I'll submit a PR for this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions