This was an ugly workaround I've built a few years ago. When you want to provide multiple paths for the inputFile parameter, you do it like this:

httplaceholder --inputFile /var/stubs1%%/var/stubs2

I've did it like this because PowerShell didn't allow comma's, but it will allow comma's if the inputFile string is wrapped with double quotes. So for PowerShell, this doesn't work:

httplaceholder --inputFile /var/stubs1,/var/stubs2

But this does:

httplaceholder --inputFile "/var/stubs1,/var/stubs2"

In all other terminals, using comma's without quotes seems to work just fine.

Long story short, this will fix a very ugly workaround I've built some time ago. Using "%%" will still work though for backwards compatability.

Think of first name, last name, address etc. There is a .NET library called Bogus which does just this.

Add a variable parser for handling client certificates.

Find out if there is such a thing as a YAML schema. If not, perhaps use JSON schema, since YAML is fully convertable to JSON. This schema can be used in VSCode for example or when adding a stub from the UI (to verify if the stub is valid).

This warning is printed out when publishing the NuGet packages. This needs to be fixed.

Instead of specifying the Content-Type header for every request, introduce a specific response writer to do this instead. This is a nice shorthand notation.

A stub with the new response writer might look like this:

- id: csv
  conditions:
    method: GET
    url:
      path: /result.csv
  response:
    statusCode: 200
    text: 'id,name,amount\n1,DukeOfHaren,20'
    contentType: text/csv

Right now, there is no paging in the UI on the requests screen. It might take a while to load if for example 2000 requests are returned.

Create and upload a Snap package.

Right now, if you want to run the HttPlaceholder Docker container with a set of .yml files, you need to pass the "inputFile" environment variable to the Docker container.

So instead of this: docker run -p 5000:5000 --env inputFile=/var/httplaceholder -v /home/dukeofharen/httplaceholder/docs/samples:/var/httplaceholder dukeofharen/httplaceholder:latest
it can be simplified to: docker run -p 5000:5000 -v /home/dukeofharen/httplaceholder/docs/samples:/var/httplaceholder dukeofharen/httplaceholder:latest
because the folder /var/httplaceholder will be used by default in the Docker container for the "inputFile" environment variable.

This is useful in several scenario's, for example if you need multiple hostnames for a specific application.

Create and upload Homebrew package.

Some software don't work well with Windows / Unix line endings. It might be a nice idea to add a feature to enforce specific line endings in a stub text response.

Create a condition checker for checking the date time. You need to be able to select UTC/local datetime, the from date/time and to date/time.
If type is not selected, the time will be considered as "local". At least from or to has to be set and can also be set both.

It might look like this:

- id: datetime
  conditions:
    url:
      path: /datetime
    datetime:
      type: utc
      from: 2020-12-24 18:00:00
      to: 2021-01-01 01:00:00
  response:
    text: Happy holidays!

For example, bla%40mail.nl doesn't match [email protected], which should be the case.

View cookie with all attributes per request in UI.

Hi!
Is it possibile to disable CORS with a single flag, instead of repeat the headers in every mock?

Matteo

For example, see https://github.com/matiassingers/awesome-readme

The configuration key configJsonLocation is case sensitive.

This works: httplaceholder --configjsonlocation /var/httplaceholder/config.json
This doesn't work: httplaceholder --configJsonLocation /var/httplaceholder/config.json

These should both work.

Would it be possible to have stub categories and group stubs by categorie in the UI ? Nice to have: make these categories collapsible/extendable in the UI.

Right now, no message is shown. Fix this.

The current header variable parser is case sensitive. So when specifying ((request_header:Content-Type)) in your request, but the actual header is called content-type, it will not be inserted in the response. This parser needs to be case insensitive.

HttPlaceholder has an official Docker image. No documentation or examples have not been written yet. Some Docker (Compose) hosting instructions and examples need to be added so people can choose their favourite way of hosting HttPlaceholder with Docker (Compose).

Add a variable handler for inserting the HttPlaceholder root URL in the response. Here is a possible example:

The stub

id: root-url-stub
conditions:
  method: GET
  url:
    path: /root-url
response:
  html: <html>((root_url))/sub/path</html>

The request

GET http://localhost:5000/root-url

The response
<html>http://localhost:5000/sub/path</html>

This is not supported right now. It isn't used very often, but apparently there are multiple valid scenario's for this: https://stackoverflow.com/questions/3241326/set-more-than-one-http-header-with-the-same-name

The current instructions are not very clear. Add separate page with different examples.

Like the title says.

Create and upload a Scoop package manifest file.

This might be handy for serving some static files from HttPlaceholder. It might look like this:

The folder

• static_files
  -- img1.jpg
  -- img2.jpg
  -- subfiles
  --- img3.jpg

The stub

- id: static-files
  conditions:
    url:
      path: /static-files
  response:
    staticFilesDir: /home/user/static_files

The request
GET http://localhost:5000/static-files/subfiles/img3.jpg

The response
The file img3.jpg.

Right now, if I want to disable a stub (if it is through a .yml file or through the UI), I delete / comment out / lower the priority of the stub. A friendlier option might be to introduce an "enabled" flag per stub for enabling / disabling the stub. If no "enabled" flag is provided, the stub is enabled by default.

Also make it clear in the UI if a stub is disabled or not.

For a first scenario, make it so that the fields in the Bearer token can be checked, just like you would do with for example a query string. Keep in mind that a Bearer token value can be an array.

Also find out how easy / hard it is to verify the JWT hash.

Add more flexibility to a stub by providing a variable parser which parses (valid) JSON, queries that JSON using JSONPath and replacing the variable in the response with the result of the JSONPath query. Here is a possible example:

The stub

- id: jsonpath-example
  conditions:
    method: POST
    url:
      path: /jsonpath-example
  response:
    statusCode: 200
    text: The result: ((jsonpath_query:$.phoneNumbers[?(@.type=='iPhone')].number))

The request

POST http://localhost:5000/jsonpath-example
Content-Type: application/json
{
  "firstName": "John",
  "lastName" : "doe",
  "age"      : 26,
  "address"  : {
    "streetAddress": "naist street",
    "city"         : "Nara",
    "postalCode"   : "630-0192"
  },
  "phoneNumbers": [
    {
      "type"  : "iPhone",
      "number": "0123-4567-8888"
    },
    {
      "type"  : "home",
      "number": "0123-4567-8910"
    }
  ]
}

The response text
The result: 0123-4567-8888

Like the title says.

No sample code in the docs yet.

Make a simple condition checker to check the cookies in the Cookie header in the request. This might look something like this:

- id: cookie-request-test
  conditions:
    cookie:
      - key: id
        value: 123
      - key: name
        value: (.*)
  response:
    text: OK cookie!

So, with the example above, the condition is correct if the following Cookie header is sent: id=123; name=anyvalue

Value can contain a regular string or a regex.

Add more flexibility to a stub by providing a variable parser which parses (valid) XML, queries that XML using XPath and replacing the variable in the response with the result of the XPath query. Also take XML namespaces in account; this doesn't really work that well in .NET. Here is a possible example:

The stub

- id: xpath-example
  conditions:
    method: POST
    url:
      path: /xpath-example
  response:
    statusCode: 200
    text: The result: ((xpath_query:/test/body/id/text()))

The request

POST http://localhost:5000/xpath-example
Content-Type: text/xml
<test>
    <body>
        <id>114</id>
        <name>Test XML string</name>
    </body>
</test>

The response text
The result: 114

Installed httplaceholder with:

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/dukeofharen/httplaceholder/master/scripts/Install-Windows.ps1'))

The documentation says:

Additionally, two additional files are also installed on the machine: _config.json and _web.config. If you want to host the application in IIS, you have to remove the _ from the filename. The _ is added to the files so the actual configuration files won't be overwritten if a new version of HttPlaceholder is installed

Where are these files located ?

Right now, if you have multiple stubs with the same conditions / response variables, you'll have to copy/paste those variables to the stubs. Let's take a look at the following example:

- id: stub1
  conditions:
    url:
      path: /stub1
    method: GET
  response:
    headers:
      CustomHeader1: value
      Header1: value1
      Header2: value2
      Header3: value3
    text: OK1

- id: stub2
  conditions:
    url:
      path: /stub2
    method: GET
  response:
    headers:
      CustomHeader2: value
      Header1: value1
      Header2: value2
      Header3: value3
    text: OK2

- id: stub3
  conditions:
    url:
      path: /stub3
    method: GET
  response:
    headers:
      CustomHeader3: value
      Header1: value1
      Header2: value2
      Header3: value3
    text: OK3

Here you have 3 stubs with the same method condition and the same response headers. It would be nice if you could provide a parent where the method condition and response headers are set. This parent can then be set on the stubs. This might look something like this:

- id: stub-parent
  conditions:
    method: GET
  response:
    headers:
      Header1: value1
      Header2: value2
      Header3: value3

- id: stub1
  parent: stub-parent
  conditions:
    url:
      path: /stub1
  response:
    headers:
      CustomHeader1: value
    text: OK1

- id: stub2
  parent: stub-parent
  conditions:
    url:
      path: /stub2
  response:
    headers:
      CustomHeader2: value
    text: OK2

- id: stub3
  parent: stub-parent
  conditions:
    url:
      path: /stub3
  response:
    headers:
      CustomHeader3: value
    text: OK3

In this case, the method condition and response headers are set on the stub stub-parent and the other stubs take that as parent. If you want to override a specific value, you can. The values defined in the child stub are always the truth.

The parent stub should not be taken into account when determining a stub to execute though.

Let's say you have the following stub

- id: stub1
  conditions:
    method: GET
    url:
      path: /img1
  response:
    file: 1.jpg
    headers:
      Content-Type: image/jpeg

This stub is located in folder /var/stubs/1. There is also a folder /var/stubs/2 that you want to read with HttPlaceholder.

When you start the application like this: httplaceholder --inputFile /var/stubs/1%%/var/stubs/2 and you go to http://httplaceholder-host:5000/img1, the image will not be resolved because the provided inputFile parameter is not a valid path. This should be the case for HttPlaceholder to find the file 1.jpg (which is located besides the stub file).

In short, what needs to happen, every path specified in inputFile should be checked iterated to find the specified file.

Show some examples how to configure stub, how to go to user interface etc.

Right now, file uploads are completely skipped. Create a condition checker which can check on file name(s), mime type(s) and in the case of a non-binary upload, file contents.

When authentication is enabled, the user needs to authenticate using basic authentication. In order for making the SignalR stuff work, a cookie needs to be set. This is an ugly hack and can be done nicer by doing authentication with a JWT. The UI will also use the JWT for authentication and authorization. The basic authentication stuff will remain for backwards compatability, but the cookie stuff will be deleted as it no longer serves a purpose after implementing the JWT auth.

This is for quickly prototyping / testing a new stub situation.

E.g. for adding a custom request condition or response writer.

The NSIS installer is not built right now. This was the case in AppVeyor, but GitLab CI doesn't support Windows shared agents out of the box.

There are 2 forms in the HttPlaceholder UI right now: one form where you can fill in the stub in YAML format and one form where you can fill in a stub in a full form. The full form will be deleted as it is very complex and a pain to maintain. The YAML stub form will get an update which makes adding a stub through that form a much better experience.

You should be able to select dimensions, background color, optional text (+ font size) and file type (jpg, png etc.).

For JPG, you need to be able to select quality (95 by default).

This is annoying and needs to be fixed.

Create and upload a Chocolatey package.

Create a response writer for HTTP cookies. It should be able to sent multiple cookies. It might look something like this:

- id: cookie-test
  conditions:
    method: GET
    url:
      path: /cookie-test
  response:
    cookie:
      - key: id
        value: 1122
        expires: 2021-01-01 00:00:00 # Optional, will be formatted by HttPlaceholder in the correct way
        secure: true # Optional
        httpOnly: true # Optional
        path: /subpath # Optional
        sameSite: strict # Optional: can be "lax", "strict" or "none"
        domain: localhost:5000 # Optional
    text: OK Cookies!

In order to send multiple cookies to the client, HttPlaceholder needs to be able to send back multiple headers. For this, #84 needs to be fixed first.

In the example above, when you send a request to http://localhost:5000/cookie-test, a Set-Cookie header with the following value will be returned: id=1122; Expires=Fri, 01 Jan 2021 00:00:00 GMT; Secure; HttpOnly; Path=/subpath; SameSite=strict; Domain=localhost:5000