WithBodyFromFile Support #45

Closed
opened 2025-12-29 14:21:35 +01:00 by adam · 7 comments
Owner

Originally created by @jrestall on GitHub (Oct 25, 2017).

Originally assigned to: @StefH on GitHub.

WireMock has support for reading the body content for a stubbed request from a file on disk.

http://wiremock.org/docs/stubbing/#specifying-the-response-body

This is very useful when body content can be very large.

I couldn't find a way to do this in WireMock.Net, I wonder if others would also like to see this support added?

Originally created by @jrestall on GitHub (Oct 25, 2017). Originally assigned to: @StefH on GitHub. WireMock has support for reading the body content for a stubbed request from a file on disk. http://wiremock.org/docs/stubbing/#specifying-the-response-body This is very useful when body content can be very large. I couldn't find a way to do this in WireMock.Net, I wonder if others would also like to see this support added?
adam added the feature label 2025-12-29 14:21:35 +01:00
adam closed this issue 2025-12-29 14:21:35 +01:00
Author
Owner

@StefH commented on GitHub (Oct 25, 2017):

Sounds ok.

Method will be like:

IResponseBuilder WithBodyFromFile([NotNull] string filename, bool cache =true);
@StefH commented on GitHub (Oct 25, 2017): Sounds ok. Method will be like: ```c# IResponseBuilder WithBodyFromFile([NotNull] string filename, bool cache =true); ```
Author
Owner

@StefH commented on GitHub (Oct 25, 2017):

@jrestall I've added some code, can you maybe do a quick review before I create a new NuGet ?

Changed code found at cbe6a0a2b4

@StefH commented on GitHub (Oct 25, 2017): @jrestall I've added some code, can you maybe do a quick review before I create a new NuGet ? Changed code found at https://github.com/WireMock-Net/WireMock.Net/commit/cbe6a0a2b411a50db30338321f730baf11f2a8ff
Author
Owner

@jrestall commented on GitHub (Oct 25, 2017):

Thanks for the amazingly quick turn around @StefH.

I have three questions,

  1. Can we also support relative paths where it defaults to a files directory as in WireMock. So passing path/to/myfile.xml could resolve to {some dir path}__admin/files/path/to/myfile.xml or similar?

  2. Would the following JSON configuration work that uses a BodyAsFile property?

{
  "Guid": "791a3f31-6946-4ce7-8e6f-0237c7443275",
  ...
  "Response": {
    "StatusCode": 404,
    "BodyAsFile ": "path/to/myfile.xml" 
  }
}
  1. A FileWatcher might be easier to use than having to specify whether each file is cached or not. Cache by default and clear the cache if a file is changed?
@jrestall commented on GitHub (Oct 25, 2017): Thanks for the amazingly quick turn around @StefH. I have three questions, 1. Can we also support relative paths where it defaults to a files directory as in WireMock. So passing path/to/myfile.xml could resolve to {some dir path}__admin/files/path/to/myfile.xml or similar? 2. Would the following JSON configuration work that uses a BodyAsFile property? ``` { "Guid": "791a3f31-6946-4ce7-8e6f-0237c7443275", ... "Response": { "StatusCode": 404, "BodyAsFile ": "path/to/myfile.xml" } } ``` 3. A FileWatcher might be easier to use than having to specify whether each file is cached or not. Cache by default and clear the cache if a file is changed?
Author
Owner

@StefH commented on GitHub (Oct 26, 2017):

1] This is possible I think.

2] JSONs could be:

{
        "Guid": "5c5b769a-7cfe-44bd-9801-a4e5fcf9bfc5",
        "Priority": 0,
        "Request": {
            "Path": {
                "Matchers": [
                    {
                        "Name": "WildcardMatcher",
                        "Pattern": "/file"
                    }
                ]
            },
            "Methods": [
                "get"
            ]
        },
        "Response": {
            "StatusCode": 200,
            "BodyAsFile": "c:\\temp\\x.json",
            "BodyAsFileIsCached": false,
            "UseTransformer": false,
            "Headers": {}
        }
    }

OR

    {
        "Guid": "55631924-791a-419e-928f-b735e312ab99",
        "Priority": 0,
        "Request": {
            "Path": {
                "Matchers": [
                    {
                        "Name": "WildcardMatcher",
                        "Pattern": "/filecache"
                    }
                ]
            },
            "Methods": [
                "get"
            ]
        },
        "Response": {
            "StatusCode": 200,
            "BodyAsBytes": "ew0KICAiaGkiOiAidGVzdCINCn0=",
            "BodyAsFileIsCached": true,
            "UseTransformer": false,
            "Headers": {}
        }
    }

3] I'll take a look....

@StefH commented on GitHub (Oct 26, 2017): 1] This is possible I think. 2] JSONs could be: ```js { "Guid": "5c5b769a-7cfe-44bd-9801-a4e5fcf9bfc5", "Priority": 0, "Request": { "Path": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "/file" } ] }, "Methods": [ "get" ] }, "Response": { "StatusCode": 200, "BodyAsFile": "c:\\temp\\x.json", "BodyAsFileIsCached": false, "UseTransformer": false, "Headers": {} } } ``` OR ```js { "Guid": "55631924-791a-419e-928f-b735e312ab99", "Priority": 0, "Request": { "Path": { "Matchers": [ { "Name": "WildcardMatcher", "Pattern": "/filecache" } ] }, "Methods": [ "get" ] }, "Response": { "StatusCode": 200, "BodyAsBytes": "ew0KICAiaGkiOiAidGVzdCINCn0=", "BodyAsFileIsCached": true, "UseTransformer": false, "Headers": {} } } ``` 3] I'll take a look....
Author
Owner

@StefH commented on GitHub (Oct 27, 2017):

3]
My idea is that you would cache small files or files which need to be served very fast.

Other files (big files) could increase the memory from a running WireMock too much, so for these files I would use the non-cached version.

@StefH commented on GitHub (Oct 27, 2017): 3] My idea is that you would cache small files or files which need to be served very fast. Other files (big files) could increase the memory from a running WireMock too much, so for these files I would use the non-cached version.
Author
Owner

@jrestall commented on GitHub (Oct 30, 2017):

Thanks @StefH, that makes sense. Again thank you so much for the quick turn-around on these enhancements.

@jrestall commented on GitHub (Oct 30, 2017): Thanks @StefH, that makes sense. Again thank you so much for the quick turn-around on these enhancements.
Author
Owner

@StefH commented on GitHub (Oct 30, 2017):

@jrestall ; the NuGet updated at https://www.nuget.org/packages/WireMock.Net/

@StefH commented on GitHub (Oct 30, 2017): @jrestall ; the NuGet updated at https://www.nuget.org/packages/WireMock.Net/
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#45