Closed CosminPerRam closed 2 months ago
Ah, i see the issue its due to the tls feature. If epic only works with tls should we exclude it unless tls is enabled as otherwise its just a bad request? I would think the majority of requests use tls so it would be the default
I think we include it by default for the cli, maybe not for the lib. Although it is very easy to disable default features. I left it disabled originally because very few of the current games use http.
We should also probably feature gate creating EpicApis to tls only: because we use from_url instead of new we don't get the type system checking that Https exists and it just falls back to http.
We should also probably feature gate creating EpicApis to tls only
this is what i was thinking.
Although im not too clued up on the http impl yet, I have only briefly looked
I was looking and possibly some form of http builder would help (Probs best for another pr), it would clean up some stuff and we can structure it where it helps us define it in a way that make it easy on our side.
eg
let client = HttpClientBuilder::new()
.protocol(HttpProtocol::Https)
.base_url(EPIC_API_ENDPOINT)
.timeout_settings(timeout_settings)
.build()?;
client can then be passed up and defined with headers and path etc
Seems like we can't do cfg stuff on phf?
Proc macro thing I think. Looks like we can either add a build script that works around it or stop using phf for games and use something like HashMap (or any other map type that doesn't need codegen to be built).
I've decided to merge this without adding asa
to the games definitions, as the problem of conditional entries for PHF should be decided in another discussion.
Closes #194.
WIP, description to be filled with stuff eventually.