Parse POST Form Data in Web 2 HandleURL

Targets Web
1

When receiving a POST in HandleURL as a Form what is the correct way to parse the form data Request.Body that is sent as application/x-www-form-urlencoded

My example of a Form data Request.Body is: itemId=123456&location=ABCDE

Do I interpret the Request.Body like it is GET using Request.Parameter?

Var myItemID As String = Request.Parameter(itemId)
Var myLocation As String = Request.Parameter(location)

I’m currently receiving the data as a GET, but I need to plan for the possibility that it will change to a POST sometime in the future when the PLC hardware that is sending the data gets upgraded.

2

Apparently not. It doesn’t look like there is a built in parser for a POST body that is a Form. I ended up having to roll my own by splitting the POST Body by “&” and then each parameter by “=”

3

Are you in control of the data being sent? I would recommend a JSON body instead of x-www-form-urlencoded.

1 Like
4

@Tim_Parnell That would be preferred on my end but this is currently a middleware app. At present the PLC can only send a GET, but the destination system needs to receive a POST with the body in application/x-www-form-urlencoded. The middleware needs to receive a POST in the same format as a GET as a backup transitional phase for a future state when a software upgrade on the PLC will allow POSTs. Once that happens we will transition the PLCS to send a POST and when verified that it works locally with the middleware we will change the URL on the PLC to be the destination system and eliminate the middleware app.

I’m not sure it is worth filing a case to add a function for parsing the Post Form data as something like:
Request.Body.FormParameter(itemId)

However, If it makes sense to you as worth requesting let me know

5

Does DecodeURLComponent help?

6

@Tim_Hare Not that I can see. It is not an issue with URL character encoding.

7

I don’t think filing a ticket for a feature request is a bad idea, but I also think you will want to write your own parser in the meantime.

It shouldn’t be too difficult:

  1. Split on & to find param=value items
  2. Split again on the = sign to separate
  3. DecodeURLComponent both the key and the value to decode anything that was encoded (like an & or an =)
8

That’s pretty much what I’m doing except I don’t need the DecodeURLComponent portion in this instance. There is no need since we can control what the PLC sends in this case, but someone else seeing this post might need it if they don’t control what is coming from the source.

I’ll try to file a ticket for parsing Form data today.

1 Like