Post Contents

[astahl]

Hi All,

Would anyone tell me in which variable are the contents of a post stored when using a memory form.
I would like to parse out some info before the save button is pressed.

Thank you,

Ashley

[Bruce]

Hi Ashley,

ok, first the general answer - then one more specific to you.
The general answer is that the incoming fields are in the Value queue. ie they've been parsed and you can retrieve them from the Value queue by using

p_web.GetValue('fieldname')

Now in your case the incoming POST is not correct for some reason, so you want to bypass the parser and just parse it yourself. (As you know, this is a bad idea because it means you are "tolerating" a bad client, and that's a terrible thing to do at this point in the client's life-cycle. It's better to know why the Post is wrong, and get it fixed.)

but to answer your question - the complete incoming data is in

p_web.RequestData.DataString

[astahl]

Hi Bruce,

Thanks for the info.

It maybe a bad idea, but I checked the incoming request and it looks fine from what I can see.

This is coming from a C# client and I have no idea what to tell him to do.
We have been working on this for 2 weeks and he is getting frustrated.
So I just want to get this working so he can send a file.

Thanks for all the help!

Ashley

[astahl]

BTW here is the post I am receiving,

POST /upload HTTP/1.1
Connection: keep-alive
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Content-Type: multipart/form-data; boundary="ed2914c5-2402-44ae-a352-936944c58236"
Content-Length: 2405
Cookie: SESSIONID=PanOhioHopeRide.org
Host: 71.8.35.230:1226
X-IMForwards: 20
Via: 1.1 web1.mgmt.eng.isc.cuyahoga.cc:80 (Cisco-IronPort-WSA/7.5.0-833)

--ed2914c5-2402-44ae-a352-936944c58236
Content-Disposition: form-data; name="uid"

test
--ed2914c5-2402-44ae-a352-936944c58236
Content-Disposition: form-data; name="pwd"

test
--ed2914c5-2402-44ae-a352-936944c58236
Content-Disposition: form-data; name="filename"; filename="TestSmall.csv"
Content-Type: application/vdn.ms-excel

Company...[rest of file contents]
 
--ed2914c5-2402-44ae-a352-936944c58236
Content-Disposition: form-data; name="pressedButton"

save_btn
--ed2914c5-2402-44ae-a352-936944c58236--

When I look at vs. what a NT client sends it all looks good.

It will parse the "uid" and "pressedButton" just fine.

But not the "pwd" or the "filename" they are blank.

Ashley

[Bruce]

hi Ashley,

>> it looks fine from what I can see.

It's what you can't see that interests me.

I'll check out the POST you've pasted, but this may not be enough. Ideally it would be great if we could get the .Net Exe to actually "do" the post. Bear in mind that there are many things that can "look" the same, or get translated in a copy and paste, that can affect parsing. The two I can think of off-hand are line endings (there are 3 possible variations) or text encoding (utf-8 etc). So the actual EXE is better. If we can't get that we can't get that, in which case other possible approaches come into play.

>> We have been working on this for 2 weeks and he is getting frustrated. So I just want to get this working so he can send a file.

I don't mean to be patronizing, but this is the root of so much eventual pain and suffering. The "I just want to hack it so it works" approach means that you have this bug somewhere that's been worked-around rather than fixed. Only sooner or later it will be fixed, and on that day "stuff stops working". Only it's a year from now, and the .Net guy has moved on, and you're concentrating on something else etc.

One approach (and what I'll be doing) is to save the incoming post into an Ascii file, then comparing it to the same post from a NetWebClient (at the byte level) to see what is different. Clearly something is different.

sure you can hack something together, but I promise you it'll bite you in the ass later on. It always does. It's _so_ much better to fix the bug, whichever end it's at, now. the fact that neither of you have much experience with this sort of thing means it's doubly important to get it right now.

Look, I have no stake in your program - I don't care what you do. I'm just hoping you avoid a bunch of pain later on.

Cheers
Bruce

[astahl]

Hi Bruce,

I really appreciate what you are saying! I also want this to work the "RIGHT" way.

So what you are asking is for is the .Net executable for testing the post correct?

If I can get it from the programmer I will and send it on to you.

Are you also saying that what shows on the NT servers text box is not an accurate
representation on what is actually being sent? 

Ashley

[astahl]

Hi Bruce,

I wanted to let you know I found the problem with the post my customer was sending!!!!!

Here is what he was posting;
Content-Type: multipart/form-data; boundary="ed2914c5-2402-44ae-a352-936944c58236"

here is what it should have been;
Content-Type: multipart/form-data; boundary=ed2914c5-2402-44ae-a352-936944c58236

.Net C# auto puts the double quote around data after the boundary='s He had to write code to stop that from happening.

Thank you for tolerating my ignorance.

Is there a way to respond back to him that the file was received using the p_web.sendpacket()

Ashley

[Bruce]

sure. He's "posting" the form, and so you should ideally send something back to him.
Question is - without you doing anything - what is he getting as a reply? chance are he's getting _something_.

cheers
Bruce

[astahl]

Hi Bruce,

I will ask him what he is getting back now. He asked about returning back to him 200.

Thanks

Ashley