Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify request body field #1735

Merged
merged 3 commits into from
Jun 15, 2018

Conversation

matiasinsaurralde
Copy link
Contributor

Solves #1724 however the Python bindings behave differently, if you had a middleware with the following code:

from tyk.decorators import *
from gateway import TykGateway as tyk

@Hook
def TestHook(request, session, metadata, spec):
  if "mystring" in request.object.body:
    print("found mystring")
  return request, session, metadata

After this change it would throw this error:

 Can't dispatch, error: <class 'TypeError'> a bytes-like object is required, not 'str'

It would need this small change:

from tyk.decorators import *
from gateway import TykGateway as tyk

@Hook
def TestHook(request, session, metadata, spec):
  if "mystring" in str(request.object.body):
    print("found mystring")
  return request, session, metadata

The request.object.body field is generated automatically by the PB tool so I'm not sure if we should modify it?
Bindings for other languages could be affected too.

@buger
Copy link
Member

buger commented May 30, 2018

Since it is backward incompatible, we need to find another solution :(

@buger
Copy link
Member

buger commented May 30, 2018

@matiasinsaurralde I wonder if we can inject some manual code to bindings we generate, so we add some byte->string conversion?

@matiasinsaurralde
Copy link
Contributor Author

@buger we could but we would need to do it everytime the bindings are re-generated and for the different languages? Also some people might be generating their own bindings

@buger
Copy link
Member

buger commented Jun 2, 2018

What about plan on adding the second field, for compatibility?

@matiasinsaurralde matiasinsaurralde force-pushed the cp-bytes-field branch 2 times, most recently from c4cbe62 to fcf8aa9 Compare June 14, 2018 03:32
@matiasinsaurralde
Copy link
Contributor Author

I've refactored this and included a test that sends multipart data and a normal JSON request, the approach is as follows:

  • When building the object we check if the data is valid UTF8 (using the unicode package), if it's valid we store a stringified version in object.body. Previously this was the standard behavior for all scenarios and the reason of the panics we had.
  • If the data isn't valid UTF8, we store it as bytes using object.raw_body (this is a new field so that we don't break existing code).

@buger
Copy link
Member

buger commented Jun 14, 2018

Nice! I would also suggest that probably raw_body should be populated all the time. So if you are writing a plugin you do not have to think about this logic of switching different fields.

@matiasinsaurralde
Copy link
Contributor Author

@buger Cool, will tweak it!

@matiasinsaurralde
Copy link
Contributor Author

Updated, raw_body is always populated now

@matiasinsaurralde
Copy link
Contributor Author

Added gRPC tests and implemented a helper for dispatcher errors

@buger
Copy link
Member

buger commented Jun 15, 2018

Now it looks really nice 👌

@buger buger merged commit 7172b91 into TykTechnologies:master Jun 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants