I have an app, two different URLs are fetched. Part of the URL is a hash which needs wildcard pattern, and I want to capture just one URL in an intercept.
But the similarity of the string makes it difficult to get a pattern that works.
/api/v1/payment/duedate?type=payment&cache_buster=...
/api/v1/payment/6309503a5c058a702224?cache_buster=... // capture this one
I tried
cy.intercept('/api/v1/payment/*?cache_buster')
It seems I need to negate specific parts of pathname or query params, but it does not seem possible to do so.
You can indeed negate a section of the URL, but not in the query parameter parts.
This will select any URL with /payment/* but exclude the one with /payment/duedate.
cy.intercept('/api/v1/payment/!(duedate*)')
You could also try a regex, or use javascript code in a routeHandler callback.
Related
I want to have a parameter with slashes in the router in gin.
From what I gathered I can do this by adding a wildcard to the URL. For example: /api/v0/files/*addr
But this approach doesn't work if I want to have the addr in the middle of the URL like /api/v0/*addr/files, and it returns this error:
catch-all routes are only allowed at the end of the path.
I was wondering whether there is another way of having it?
Seems that is a limitation of the Gin framework, as seen # https://github.com/gin-gonic/gin/blob/master/tree.go#L322
You could always invert the order and do a rewrite using a proxy and a regexp (i.e. /api/v0/*addr/files to /api/v0/files/*addr) or only accept methods ending with /files inside your handling function, but I'm afraid that is a hardcoded limitation of the Gin framework.
I'm trying to use Spring's ServletUriComponentsBuilder to create paging next and prev links from the current request.
The problem I'm having is that the ServletUriComponentsBuilder.fromCurrentRequest() is not unencoding percent-encoded values like:
http://example.com/articles?page%5Bnumber%5D=2
The problem is uses could have called the page with unencoded square brackets like http://example.com/articles?page[number]=2 without any problems.
Spring Data is accepting both variants (both unencoded square brackets and encoded square brackets) in it's pageable argument resolver.
This to the fact that under water the Coyote web request get parameter is used which contains the unencoded param names.
Also Spring's #RequestParam("page[number]") accepts without any problem the encoded request like http://example.com/articles?page%5Bnumber%5D=2.
From the server side I always want to return percent encoded url's as per RFC 3986.
But there does not seem a way to this as the UriComponents query params might contain both encoded en uncoded names. Because to that, if I would call encode() on the builder the already encoded query params get encoded another time, but if would contain unencoded names toURI() will fail as an unencoded [ is not allowed.
Note that the url's might contain multiple query params besides paging, e.g. for filtering.
A request could come in like:
http://example.com/articles?filter[category]=food
And would return a response with a encoded next link like:
http://example.com/articles?page%5Bnumber%5D=2&filter%5Bcategory%5D=food
My workaround it to ignore ServletUriComponentsBuilder and simply get the request url and do so custom regexp replacing.
I know this is an older question and you also found a workaround. But did you try to use ServletUriComponentsBuilder's build() method?
Some kind of the following:
ServletUriComponentsBuilder.fromCurrentRequest().build().toUriString();
I had some issues when handling JSON Strings and this helped.
This question has been asked a few times but I can't seem to find a solution that helps me which is why I am trying here.
I have my site setup with the following for URLs I am using CodeIgniter I have a controller called user which loads a user view.
So my URLs are structured as follows:
http://example.com/user/#/username
I want to try and strip out the user controller from the URL to tidy up my URL so they would just read:
http://example.com/#/username
Is this possible I have been looking at route and have tried lots of different options but none have worked?
$route['/'] = "user";
Could anyone offer any solution?
Assuming the '#' in your URLs is a valid function and 'username' is a parameter for that function, then this route should work:
$route['#/(:any)'] = "user/#/$1";
Depending on what usernames are to be routed you may want to change the wildcard. For example, if you only wanted to route numbers as the parameter, you could change (:any) to (:num).
(:num) will match a segment containing only numbers.
(:any) will match a segment containing any character.
You can also use regular expressions to define routing rules, allowing you to further restrict what is routed.
I am building a results filtering page using AJAX requests. I would like to reflect the filters in the URL. For example: for price_from I want to add ?price_from=VAL to the URL.
I have a backend that is capable of rendering the page with URL parameters.
After some googling I would a Backbone.router solution which has a hash fallback for the IE that does not support HTML5 history API.
I have a problem with setting a good philosophy of routes. I have a set of filtering parameters (price_from, price_to, color, ...) and I would like to attach each parameter to one route.
Is that possible to chain the routes to match for example: ?price_from=0&price_to=1&color=red? (the item order can change)
It means: call all the routes at the same time and keep the ie backwards compatibility?
Your best bet would be to have a query portion of the URL rather than using GET parameters to denote the search criteria. For example:
Push state: /search/query/price_from=0&price_to=1&color=red
Hash based: #search/query/price_from=0&price_to=1&color=red
Your backend would of course need to change a bit to be able to parse the new URL structure.
In my page I ve to pass multiple values to controller.
My URL looks something like :
http://blah/Search/Page/?type=new&keywords=blahblah&sortType=Date
Is Passing multiple values as query string good practice in MVC ? or We can have slash separated URL, by using introducing custom routing?
NB: Lets consider all the values in my query string, are not secure / sensitive data.
I wouldn't consider it a bad practice, as long as it's not senstive data. It just depends if you want to write a custom route in your global.asax to handle it or not. The custom routes provide a cleaner url forsure. Also, for more savy users if they understand the concept on your site, it's more intuitive.
So consider this:
http://baseballcards/topps/1980 // search for baseball cards made by topps in the 1980s
http://recipes/deserts/pies // search for a desert recipe that are pies
http://code/csharpe/linq // search for csharp code that has linq examples
In these examples we can almost read the url like a sentence, making it more intuitive, giving a user the ability to plug and play. It clearly denotes the query almost like a breadcrumb, indicating exactly what the context will be. I personally like this. But either way is a good approach.
To extend with more parameters:
routes.MapRoute(
"SearchRecipes",
"Search/Recipes/{category}/{type}",
new { controller = "Search", action = "Recipes", category = "all" , type = ""}
);
Some examples:
Search/Recipes/Deserts/Pie
Search/Recipes/Dinner/Beef
Search/Recipes/Lunch/Salads
Select later (query string in route values) in case,
If you are concerned about header length.( By default get parameters are part of headers, and web server accept 1024 byte header length by default in IIS7).
Hide logical implementation of your code.
Url looks good and easier to remember.
Otherwise Both the approaches work equally.
I think passing search parameters in the query string is the way you should go, especially if all your parameters are optional. It also enables you to use normal method="get" forms without hassle.
I don't think "security/personal data" has anything to do with this since the query string is a part of the URL just like the path is.
IMO I think this is absolutely fine. I think it is actually preferable to use querystrings in MVC when the path represents the function and the querystring parameters represent the filters, e.g. as in a search.
However, I wouldn't use querystring parameters for data that represent information about the content retrieved. So I would include the year and month of an article in the path but not the page number if returning more than one page of articles for the year and month.