❔ HTTPclient fails to POST properly
Target website has a very basic login form, and I have no problems logging in via curl:
However, attempt to sent POST with HttpClient always fails:
The response should be
302 Found
and then response header contain redirect to profile location, but I'm not getting it. I do get it with curl tho. So the issue is with Httpclient.
Any idea what cold be the differences between curl and HttpClient that make the former work?25 Replies
Does said website allow requests to a non-official api?
curl works just fine
I'm not talking about if it works.
I'm talking about the terms of service.
but I'm not getting itWhat are you getting?
200 OK which is a normal request to
session/login
page, should be 302 found + redirect
I really dont want to spend gazzlion of effort for the next few days making BURP work with https, so I can just inspect difference in headers, it is pain
I was wondering may be someone who uses both curl and HTTP client knows where the former excels by default so I can just use the infoI notice the referrer is different... But we're just taking it on trust that you've got all of the headers correct.
First thing I'd check is the response body, see whether it contains e.g. an error message saying what's wrong.
Second is to get fiddler up and running. It won't take a "gazillion" -- it'll take a few minutes, and you'll be able to see the exact difference between those two
I've compared the headers, here aint that much to differ,
Content-type
, User-agent
(not even needed but for posterity) and cookie, that is.
I will try fiddler, hopefully it is less pain then BURPWell, headers and body params, I mean
I would just take a look at the response -- the server might be telling you what's wrong
And yeah, fiddler is great. Sorts out its own SSL certs (I think you might need to click a button?), etc
Use Fiddler and find the difference in the two requests made
lmao it does not work for my location, rip
ah, I see fiddler somewhere in this convo
God I really have to go back to BURP Community and that cert nightmare
But yeah it does not make any sense for any header dot content do not match, I've printed the FormURLEncoded data and it is exactly what I send with cURL, same with the headers, cookie is added via
DefaultRequestHeaders
I dont think it has anything to do with it, I think it is some default client setup between curl and HTTPClient, the former just have it being sent by default because it is often used as REST API debugging tool so it makes sense to hone it for that case, where was HttpClient
is too generic
Essentially my question boilds down if anyone else stepped on the same rakes and figured the differences outHuh, it used to be entirely free, last time I looked
That's a shame
Huh, so there is no default
Accept: */*
for httpclient
HTTPToolkit shows the request is pretty much exactly the same, sans Accept which I can add but it wont change anything
@canton7 you have experience sending binay data (images) as mutipart form with boundary with HTTPclient?
Do I need to compose it myself or is there a built-in boundary breakYeah there's a content class for that
MultipartContent Class (System.Net.Http)
Provides a collection of HttpContent objects that get serialized using the multipart/* content type specification.
nice, thanks!
Do you know what the proper container to send content raw as in the example on the left:
If there is a way to avoid serializing rawstrings to bytes I will take it but otherwise I will go that way
You mean, remove the content-type header?
Just remove it from the HttpContent
No I meant per entry, I'm just gonna go for ByteArrayContent for these strings.
However I still have this. Not sure where can I specify MIME type for only last part of the payload, which is JPEG:
I'm confused as to what you want... Were you using a
StringContent
before, but you didn't want a Content-Type header?
Just remove that header from the StringContent. It's added by default, but you can remove it
Or there are constructors which let you set the value of that header explicitly
new StringContent(string content, (Encoding?)null, (MediaTypeHeaderValue?)null)
might do it?@canton7 ah no, I figured it out, you need to force content type per payload:
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.