cancel
Showing results for 
Search instead for 
Did you mean: 

ServiceV Pro: Default response unexpectedly replacing the scripted one

SOLVED
Community Hero

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

@MeT:

 

Hi,

 

Thank you a lot for the update. I did not try it yet, but certainly will do. Smiley Happy

Initially, your solution seemed to me to be a kind of workaround and I was going to suggest to create either an issue or feature request.

However, after some consideration, I am already less confident and tend to consider your solution as a valid and correct approach. I did not check what standard says about duplicated slashes within and at the end of address, but from what I remember, browsers usually ignore duplicated slashes and navigate to the same resource.

For example, https://support.smartbear.com////versions/// navigates to the same page as https://support.smartbear.com/versions/ and https://support.smartbear.com/versions.

 

So, even though your given virt contains template parameter at the end of the path, it looks reasonable that if this final parameter is missed, then the path still looks like a valid REST path (for example, like a request to get IDs of all creditors for the given subject) and ServiceV has no good reason to consider that this is a request with the missed last parameter. And thus it returns default internal 404 because no virt was specified for the requested resource.

This is my current understanding and explanation. Do you think I missed something ?

 

@Olga_T:
Olga, is it possible to ask your technical writers to extend the documentation section for Template parameters with the description of ServiceV behavior when the final parameter in the path is missed and what actions must be done in this case, based on the approach by @MeT? Thank you.

 

Regards,
Alex
[Community Expert Group]
____
[Community Expert Group] members are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Postings made by [Community Expert Group] members
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
[Community Expert Group] signature is used with permission by SmartBear Software.
http://smartbear.com/forums/f83/t86934/community-experts/
================================
Moderator

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

@AlexKaras,
Sure, I have assigned a new task to our Documentation team in our internal system based on your request.


Olga Terentieva
SmartBear Assistant Community Manager

MeT
Occasional Contributor

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

@AlexKaras

Hi Alex,

I believe your understanding as described in your post is correct.

From my side, I just want to add some additional details, which my conclusions are based upon.

If you test the following URLs in Chrome or Firefox, you'll be seeing the following behaviour in their address bar:

  1. https://www.google.nl    =>    https://www.google.nl
  2. https://www.google.nl/   =>    https://www.google.nl    <<< Forward slash is stripped out
  3. https://www.google.nl//  =>    https://www.google.nl//  <<< Forward slashes are not stripped out

The reason of this behaviour is that a double forward slash represents a path segment, and apparently it doesn't matter if its value is an empty string or not, as long as the part of the URL preceeding it is a valid URI.

The test paths I have provided in my previous posts have been designed with this consideration in mind. For all those paths where the second argument is missing, it's up to us to provide suitable fallback resources, in order to be able to handle them correctly and eventually dispatch a custom response.

 

Please let me know if this helps clarifying the matter even further. Smiley Happy

Community Hero

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

Hi,

 

Back from my vacation and returned to scenario by @MeT as it is still pretty good for my self-education Smiley Happy

 

I did not check whether or not it is specified in RFCs, but from the end-user tester's point of view I tend now to consider the approach marked as solution to be a workaround instead.

As I see it now, virt developer (i.e. tester) must provide at least those requests for the virt:

-- /subject/{subject_nr}/mandate/{creditor_id} -- main scenario;

-- /subject/mandate/{creditor_id} -- for missed {subject_nr} parameter with removed '/' in the path;

-- /subject/{subject_nr}/mandate/ -- for missed {creditor_id} parameter;

-- /subject/mandate/ -- for both parameters missed

 

Besides that, tester must carefully think what request to call from ServiceV while verifying this or that combination of parameters. And this is, obviously, pretty inconvenient.

 

It seems to me at the moment, that it would be more convenient if (for requests declared as those with parameters in the path) ServiceV consider the possibility of some parameter to be empty and ignored the number of the subsequent slashes in case the parameter is missed.

E.g. :

/subject/123/mandate/aaa

/subject//mandate/aaa

/subject/mandate/aaa

/subject/mandate/

/subject//mandate//

all should be dispatched to the same

/subject/{subject_nr}/mandate/{creditor_id}

template request and then it must be tester's responsibility (via dispatching script) to handle missed parameters as required.

 

@Olga_T, @TanyaGorbunova: Ladies, could you please ask architects'/developers' opinion about this case and, unless it contradicts some RFC section, let us know whether we may report this as an issue or feature request.

 

Regards,
Alex
[Community Expert Group]
____
[Community Expert Group] members are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Postings made by [Community Expert Group] members
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
[Community Expert Group] signature is used with permission by SmartBear Software.
http://smartbear.com/forums/f83/t86934/community-experts/
================================
MeT
Occasional Contributor

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

@AlexKaras

Hi and welcome back, hope you enjoyed your vacation! Smiley Happy

I'd like to ask you to think for a moment to the semantics of the following paths:

1. /subject/{subject_nr}/mandate/{creditor_id}   >>> path featuring 2 template params: when filled in, it validly represents a possible URI
2. /subject//mandate/{creditor_id}   >>> path featuring 2 template params, where the 1st one is missing, it does NOT validly represent a possible URI
3. /subject/mandate/{creditor_id}   >>> path featuring 1 template param: when filled in, it validly represents a possible URI
4. /subject/mandate//   >>> path featuring 1 missing template param: it might validly represent a possible URI only if you drop the last forward slash
5. /subject/mandate/   >>> path featuring 0 template params: it validly represents a possible URI
6. /subject/mandate   >>> path featuring 0 template params: it validly represents a possible URI

Consequently, in case of paths 4, 5 and 6, it's reasonable to expect a status code 404 Not found, if you didn't take care of implementing support for path 6 in your service.

 

Hope this helps! Smiley Wink

Highlighted
Moderator

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

Hi all,

 

@AlexKaras, sure, I have contacted one of our engineers regarding the query. They should look into it shortly.

I will get back to you as soon as I have any updates.

 

 


Olga Terentieva
SmartBear Assistant Community Manager

Moderator

Re: ServiceV Pro: Default response unexpectedly replacing the scripted one

Hi all,

 

I've got some updates from the developers. It looks like the investigation can take long, so the best way to proceed here is to create a support ticket. 

 

@MeT, it would be great if you could later share your results with us here Smiley Happy

Thanks in advance!

 


Olga Terentieva
SmartBear Assistant Community Manager

New Here?
Join us and watch the welcome video:
Join the exciting event
SeptemberHubBub
Top Kudoed Authors
Join the September Hub-bub to show off, learn and win