* fix: Prevent spamming /health endpoint and improve startup and resolve compiler warnings
This commit introduces a delay and improved logic to the /health endpoint checks in the llamacpp extension, preventing excessive requests during model loading.
Additionally, it addresses several Rust compiler warnings by:
- Commenting out an unused `handle_app_quit` function in `src/core/mcp.rs`.
- Explicitly declaring `target_port`, `session_api_key`, and `buffered_body` as mutable in `src/core/server.rs`.
- Commenting out unused `tokio` imports in `src/core/setup.rs`.
- Enhancing the `load_llama_model` function in `src/core/utils/extensions/inference_llamacpp_extension/server.rs` to better monitor stdout/stderr for readiness and errors, and handle timeouts.
- Commenting out an unused `std::path::Prefix` import and adjusting `normalize_path` in `src/core/utils/mod.rs`.
- Updating the application version to 0.6.904 in `tauri.conf.json`.
* fix grammar!
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* fix grammar 2
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* reimport prefix but only on Windows
* remove instead of commenting
* remove redundant check
* sync app version in cargo.toml with tauri.conf
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Things to ponder:
- Now, the v1/models endpoint of the API server will return an empty
list if no models are loaded
- Streaming v1/chat/completion routing works as well as v1/models; needs
further testing
- Add filtering logic to proxy server for GET /models requests
- Keep only models with status "downloaded" in response
- Remove Content-Length header to prevent mismatch after filtering
- Support both ListModelsResponseDto and direct array formats
- Add comprehensive tests for filtering functionality
- Fix Content-Length header conflict causing empty responses
Fixes issue where all models were returned regardless of download status.
* fix(server): enhance CORS handling for local API network access
- Fix CORS preflight validation to use Host header for target validation
- Use Origin header correctly for CORS response headers
- Improve host validation to support both host:port and host-only formats
- Filter upstream CORS headers to prevent duplicate Access-Control-Allow-Origin
- Add CORS headers to all error responses for consistent behavior
- Fix host matching logic to handle trusted hosts with and without ports
- Ensure single Access-Control-Allow-Origin header per response
This resolves CORS preflight failures that were blocking cross-origin
requests to the local API server, enabling proper network access from
web applications and external tools.
Fixes: OPTIONS requests being rejected due to incorrect host validation
Resolves: "access control allow origin cannot contain more than one origin" error
* fix(proxy): bypass host and authorization checks for root path in CORS preflight
* fix(proxy): bypass host and authorization checks for whitelisted paths
* feat: Jan API Server should have API Key setting
* chore: reveal api key icon
* Update src-tauri/src/core/server.rs
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* chore: add validation apiKey
---------
Co-authored-by: Faisal Amir <urmauur@gmail.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
