Forum Discussion
5 Replies
- Hi!
thanks for reporting, this shouldn't be.. Can you attach a WADL that gives you this?
regards!
/Ole
eviware.com - Gordon_McNairContributor
- Hi Gordon,
thanks! If you double-click the imported PUT method you should see that the Authorization parameter has been correctly initialized as a HEADER parameter, and when you send the request its value will be added as an HTTP Header instead of a standard Query parameter. Is this not the behavior you are getting?
Also, regarding the PLAIN parameters, these are currently ignored when sending.. is that ok for you or would you like them to be handled in another way? (as a standard query parameter maybe?)
regards!
/Ole
eviware.com - Gordon_McNairContributorThanks for that I see that in the put method parameters but I couldn't see that in the request (which is where I was looking). It appears to work as a standard header but, it is URL encoding the content which is not correct for the authorisation header. I've created a script that adds the 'basic' key word and base 64 encodes the supplied password. Is there another way to do this with passwords that change for each request?
Thanks for your help - Hi,
thanks.. I've fixed the upcoming build to not url-encode header parameters. Regarding the Base64-encoding of parameter values, you could try the following:
1) Define a property holding the value of the parameter (ie your password)
2) Set the parameter value to a script: ${=Base64.decode( context.expand( '#TestCase#Password' ))}
(this isn't entirely correct but you get the idea..)
Would that work?
regards!
/Ole
eviware.com