mirror of
https://github.com/ProxymanApp/Proxyman.git
synced 2026-05-01 11:05:56 +03:00
[GH-ISSUE #373] Unusual behaviour for response headers keys registry #369
Labels
No labels
Discussion
Feature request
In Progress...
Plugins
Waiting response
Windows
Windows
bug
duplicate
enhancement
feature
good first issue
iOS
macOS 10.11
question
wontfix
✅ Done
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Proxyman#369
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fulldiver-ilya on GitHub (Jan 13, 2020).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/373
Originally assigned to: @NghiaTranUIT on GitHub.
Proxyman version: 1.13.1
macOS Version: 10.15.2
Hey! Thanks a lot for an amazing tool, but I have a question...
I'm developing iOS application with Alamofire (most common 3-party network library) and using http-headers from our internal server responses. Alamofire provides case-insensitive keys for all headers (they are all lower-cased).
But there is a problem when I use Proxyman: after getting response that pass through Proxyman I have a case like
X-Custom-Header. When I toggle-off proxy I getx-custom-headeras I expectIs any way to change or understand this behaviour?
@NghiaTranUIT commented on GitHub (Jan 14, 2020):
Thank for the report @fulldiver-ilya. Technically, all Field Headers are case-insensitive (https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2), so the behavior of the app from end-users should not changed.
However, you're right that Proxyman
implicitly capitalizes it. I will improve this behavior by:I'm on it and send you hot-fix build in this week 👍
@NghiaTranUIT commented on GitHub (Jan 14, 2020):
Hi there, so far from what I investigated that Proxyman doesn't support HTTP/2 since we're heavily relied on CocoaAsyncSocket, which isn't supported it.
I tested with a testing server:
In the initial thought, It might be easy, but actually it's difficult since I have to find a way to support HTTP/2 in CocoaAsyncSocket.
About your case, I believe that your connection from iOS app is downgrade to HTTP/1.1 and the Header in the response from your server are uppercase => Proxyman sends back to the app =>
X-Custom-HeaderCan we @fulldiver-ilya lowercase in your app again to make sure it works in both HTTP/1.1 and HTTP/2?
@fulldiver-ilya commented on GitHub (Jan 15, 2020):
Sorry for late answer but yes, our server is working over http/2.0 with SSL and Proxyman downgrading answer to http/1.1
Proxyman answer:
Charles answer:
Is it answer to your guess?
@NghiaTranUIT commented on GitHub (Jan 16, 2020):
Yup, it's correct as I mention that Proxyman currently doesn't support HTTP/2. I'm looking on it to support HTTP/2 soon.
@NghiaTranUIT commented on GitHub (Jun 17, 2020):
Hey @fulldiver-ilya , the good news that Proxyman 2.0.0 is re-written with Swift NIO (https://github.com/ProxymanApp/Proxyman/issues/500), which is capable of supporting HTTP/2.
Let bump this feature forward 🙌
@fulldiver-ilya commented on GitHub (Jun 17, 2020):
Hey @NghiaTranUIT its a great news! Congrats 🎉
@nunogoncalves commented on GitHub (Dec 9, 2021):
Hello,
We are seeing the same. an API is returning capitalized headers, and after passing by Proxyman they are lowercased.
Is there any configuration to fix this?
@NghiaTranUIT commented on GitHub (Dec 9, 2021):
Just wondering: Do your request/response use any debugging tools?
In the latest build, Proxyman is using HTTP/1.1, so all Headers are capitalized on the first character, and Proxyman doesn't modify any Header by default.
@nunogoncalves commented on GitHub (Dec 9, 2021):
Ok, I think we got it. If we make the request using curl —http1.1 it shows us Auth-Token. If we set it for —http2.0 it lowercases it. I'm unsure to what the correct behaviour should be. :D
@nunogoncalves commented on GitHub (Dec 9, 2021):
So, our app, iOS is seeing the header
auth-tokenwithout Proxyman in the middle, (which seems to support the idea that it supports http 2.0 (according to docs). If we use Proxyman, it showsAuth-Token. If Proxyman supports HTTP2, shouldn't it beauth-tokeninstead? Maybe I'm missing something here.@NghiaTranUIT commented on GitHub (Dec 9, 2021):
In HTTP/1.1, it's Auth-Token (capitalized on the first character). In HTTP/2, all header is lowercase.
Proxyman hasn't implemented HTTP/2 yet, so all Header will be
Auth-Token@nunogoncalves commented on GitHub (Dec 9, 2021):
Ah! Sorry!
So I'm confused to this messagE:
So, Swift NIO supports HTTP/2, but Proxyman doesn't, yet.
@NghiaTranUIT commented on GitHub (Dec 9, 2021):
ah, yes, sorry for the misunderstanding. It means, Proxyman, powered by SwiftNIO, can support HTTP/2/ in the future. It's easier than the v1.0, which uses bunch of raw socket 😄
HTT/2 is still in our road map 👍
@nunogoncalves commented on GitHub (Dec 9, 2021):
Thanks for your answers.
BTW, I got to say. This was by far the best open source experience I've ever had! It never crossed my mind that I'd get answers in 3 minutes! :D
Also this is one my favourite apps on my Mac, so awesome work! And thank you for that as well!
@NghiaTranUIT commented on GitHub (Dec 9, 2021):
Thanks. Glad to know that you really enjoy the app 😄 ❤️
@stodirascu commented on GitHub (Nov 21, 2022):
+1 for the awesomeness of the app 🎉
And +1 to solve this issue. I've stumbled across it recently and baffled me a bit till I understood what's going on. Is there a way to upvote this to switch to HTTP/2 sooner than later?
@NghiaTranUIT commented on GitHub (Nov 22, 2022):
Thanks folks to bump the HTTP/2. I will put it in the high priority queue to implement it 👍