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

Deck convert from 2.x to 3.x does not handle the escape characters in the regex paths #1310

Open
shambhand opened this issue May 29, 2024 · 3 comments

Comments

@shambhand
Copy link

Input

  routes:
  - https_redirect_status_code: 426
    methods:
    - POST
    name: excelReader-route
    path_handling: v0
    paths:
    - /excelReader/([^\/]+)

deck file convert --from kong-gateway-2.x --to kong-gateway-3.x --input-file {input_file} --output-file {output_file}

Expected output:

  routes:
  - https_redirect_status_code: 426
    methods:
    - POST
    name: excelReader-route
    path_handling: v0
    paths:
    - /excelReader/([^/]+)

After converted file from 2.x to 3.x output, while syncing got an below error

while processing event: Create route excelReader-route failed: HTTP status 400 (message: "validation error")
@Tieske
Copy link
Member

Tieske commented May 29, 2024

This is not a conversion of Kong formats. It is a stricter regex rule. The escape (the \) in not necessary, some regex engines accept it, and some don't. So this is not covered in the conversion.

@shambhand
Copy link
Author

@Tieske Thanks for the response.
We have so many route's paths contains the regex with escape character paths; carried from kong 1.x to 2.x.

Now we are trying to migrate to kong/konnect 3.x.

I guess the earlier version of the kong was requiring to have the escape characters for route's regex paths.

Would there be a problem or any issue if it would be handle as part of deck 2.x to 3.x conversion? Considering kong 3.x routes creation API does not even accept the escape character for regex paths.

@Tieske
Copy link
Member

Tieske commented May 30, 2024

It would mean trying to interpret a regex and guessing how to resolve the situation. I do not think there is a fool proof way of doing that conversion.

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

No branches or pull requests

2 participants