ProxymanApp / ProxymanApp/Proxyman
解析 protobuf response body 提示找不到 消息类型
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 7k
- Forks
- 237
- PR merge metrics
- No merged PRs in 30d
Description
Description
Based on https://docs.proxyman.io/advanced-features/protobuf#2.-protobuf-file-descriptor-.desc,
I generated the all.desc file.
After importing it and specifying the return structure as RestClientResponse,
the Protobuf tab in the response shows a prompt indicating that RestClientResponse cannot be found.
The response contains data: "JBOEgdTdWNjZXNzGiRmZDdiZWM1My1lNDdlLTRmYmMtYWExNC05NzI2ZWVjZDI4MTki". What could be the reason for this?
Also, using the command line
protoc --decode=RestClientResponse --descriptor_set_in=all.desc < response_body2.bin
can parse out the following content:
error_code: 10000
error: "Success"
request_id: "ab66d155-40a0-47ad-a411-1a6a02868328"
data: "\020\003*\352\020\010\001"\225\017\010\001\022\220\017\010\365\331\204\226\353\312\200\t\020\350\275\360\334\0032s\n 3b9ae203la1hdmgi3z3crj20yi0p0q2z\020\332\t\030\204\007*Ih....................................
Here, the data is another structure IndexPageResponseDataV3 (I only listed a part).
Is there a problem with my settings or is there an issue with the all.desc file?
Additionally, when using charls to import this all.desc file to parse the response,
it prompts invalidProtocolBuffer Exception$invalidWireTypeException: protocol message tag had invalid wire type.
Please take a look when you have time. Thank you very much.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Protobuf tab behavior using the imported all.desc file and the response data described in the issue. Compare its result with protoc --decode using response_body2.bin, then check the charls parsing failure; done means the cause of the missing RestClientResponse or invalid wire type is identified and the response can be parsed consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos
- Domain
- api, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100