support passing http.Header to exported functions #37
Conversation
In doing this we allow the user of the library to pass nil, getting the current default behaviour, or specify a header. This header can then be used to indicate to the Tika server the response format that is required. This should be useful to folks because Tika can respond with HTML, plain text, or json. At this point I've not added any validation in here. My assumption is that the Tika server will handle that. I updated the tests to nimply use nil for this new parameter. If it is wanted I could look to add some new tests that exercies different response types. It may also be nice to update the cli tool to allow the user to indicate the type of response required. Given the definition of the issue though that felt out of scope here. I hope this is helpful.
|
I have a small tool I'm using this in locally. I've been able to use the code on this PR and verify the results are as I expected. |
|
Thanks! I'm good to add support for headers, but I'd prefer not to make a breaking change to the API. Just to throw something out there, what if we had something like |
|
I'll do that for sure, makes total sense. It'll be sometime this week that I get to it. I should've done a |
This adds two new Parse functions, ParseWithHeader and ParseReaderWithHeader. I've also added a specific test case here for the ParseWithHeader function to ensure it is using the header correctly. The other change here, which no longer breaks the API, is to have the original Parse and ParseReader simply call the new WithHeader versions setting a nil header. This approach means that we still only have one place where call and callString are called but that we also have the ability to have headers or not.
|
Instead of Hopefully what I've done makes sense here. It no longer breaks the API, doesn't require the caller to have multiple copies of the client for different headers, and it should be clear and obvious how to use it. |
tika/tika.go
Outdated
| @@ -185,35 +197,35 @@ func (c *Client) ParseRecursive(ctx context.Context, input io.Reader) ([]string, | |||
|
|
|||
| // Meta parses the metadata from the given input, returning the metadata and an | |||
| // error. If the error is not nil, the metadata is undefined. | |||
| func (c *Client) Meta(ctx context.Context, input io.Reader) (string, error) { | |||
| return c.callString(ctx, input, "PUT", "/meta") | |||
| func (c *Client) Meta(ctx context.Context, input io.Reader, header http.Header) (string, error) { | |||
There was a problem hiding this comment.
Looks like this still has the new header arg.
There was a problem hiding this comment.
For sure. I'll fix it up. The issue with making the changes before breakfast this morning 😂
This applies the same changes as have been made to Parse. I've also added a couple of extra tests to ensure the header is sent over correctly. Apologies for missing this before.
|
Apologies for missing the |
Conflicts:
.gitignore
This conflict has been resolved.
Also ran go fmt, my editor had already run goimports so that yielded no changes. go mod did update the mod files.
|
Looks like |
In doing this we allow the user of the library to pass nil, getting the current default behaviour, or
specify a header. This header can then be used to indicate to the Tika server the response format that is required.
This should be useful to folks because Tika can respond with HTML, plain text, or json. At this point I've not added
any validation in here. My assumption is that the Tika server will handle that.
I updated the tests to nimply use nil for this new parameter. If it is wanted I could look to add some new tests that
exercies different response types. It may also be nice to update the cli tool to allow the user to indicate the
type of response required. Given the definition of the issue though that felt out of scope here.
I hope this is helpful.