Starcounter
HomeDownloadDocsCommunity
2.3.1
2.3.1
  • Starcounter Documentation
  • Getting Started
  • Starcounter
    • Collapsing the Stack
      • Complexity and Scalability Tradeoff
      • The Future of Micro-Services
      • 10 Benefits of Collapsing the Stack
    • Integrated Database and Web Server
  • Hello World - Tutorial
    • Create a Database Class
    • Create a Real Time UI
    • First Interactive UI
    • Computed Properties
    • Expense Tracker
    • Cancel and Delete
    • The Next Step
  • Guides
    • Database
      • Database Classes
      • Data manipulation
      • Object Identity and Object References
      • Querying with SQL
      • Data Types
      • Relations
      • Inheritance
      • Sharing data
      • Database Configuration
      • Comparing Database Objects
      • Referential Integrity and Constraints
    • SQL
      • Identifiers
      • Path Expressions
      • Data operators
      • Joins
      • Aggregates
      • Comparisons and Logical Operators
      • Sorting
      • Fetch
      • Offset Key
      • Indexes
      • Literals
      • Query Plan Hints
      • Reserved words
      • Query for Database Classes
      • SQL Isolation Between Applications
    • Transactions
      • Short-Running Transactions
      • Long running transactions
      • Using Transactions
      • Running Background Jobs
      • Commit Hooks
    • Typed JSON
      • JSON-by-example
      • Code-Behind
      • Data Bindings
      • Callback Methods
      • Responding with JSON
      • Accepting JSON in Requests
      • Primitive Arrays and Single Value Types
      • Typed JSON Internals
    • Blendable Web Apps
      • Starcounter MVVM
      • Palindrom
      • Client-Side Stack
      • Sessions
      • HTML Views
      • App Shell
      • Web Components
      • View Attaching
      • View Composing
      • HTML Compositions
      • HTML Views Blending Guidelines
      • Avoiding CSS conflicts
      • Debugging
    • Network
      • HTTP
      • Internal Self Calls
      • Middleware
      • Anonymous or Substitute Handlers
      • URL Aliases and Redirects
      • Network Gateway
      • Static File Server
      • External HTTP Calls
      • WebSocket
      • Avoiding URI conflicts
      • TCP Sockets
      • UDP Sockets
    • Publishing Apps
    • Working with Starcounter
      • Release Channels
      • Starting and Stopping Apps
      • Administrator Web UI
      • Star CLI
      • StarAdmin CLI
      • StarDump CLI
      • Working in Visual Studio
      • Error Log
      • Using HTTPS on NGINX
      • Using HTTPS on IIS
      • Run Starcounter in Production
      • Weaver
      • Investigating App Crashes
      • Configuration Structure
      • Database Refactoring
      • Using Unload/Reload to Modify Database Schema
      • Kernel Questions and Answers
      • Log Files
  • Cookbook
    • Attach an HTTP Request to an Existing Long-Running Transaction
    • Cookie-Based Authentication
    • Timestamp on Object Creation
    • Creating Strongly Typed JSON Collections
    • Migrating From 2.2 to 2.3+
    • Multiple Pages
    • Icons
    • Proposed Project Structure
    • Acceptance Testing with Selenium
    • Requesting a User to Authenticate
    • How to delete unused tables and columns
Powered by GitBook
On this page
  • Introduction
  • Namespacing dynamic HTTP handlers
  • Namespacing static HTTP resources
  1. Guides
  2. Network

Avoiding URI conflicts

PreviousWebSocketNextTCP Sockets

Last updated 7 years ago

Introduction

There are some HTTP "namespacing" precautions that you need to take to make your app run safely alongside other apps.

Namespacing dynamic HTTP handlers

Your app should only create HTTP handlers (using Handle.GET, Handle.POST, etc) that begin with the app name. For example:

Handle.GET("/myapp", ()
{
  var page = new MyAppHomePage();
  return page;
});

By default it is not enforced. You might enforce it by enabling a database configuration flag: .

Namespacing static HTTP resources

The above principle should also be used for the static resources that are exposed from the wwwroot subdirectory in your app.

All the files that are unique to your app (HTML templates, CSS stylesheets, custom JavaScript) should be placed under wwwroot/<appname>.

For example a file saved as wwwroot/myapp/style.css will be exposed by the static HTTP server as . You don't have to worry that some other app will overwrite style.css, because it will use it's own directory for the file.

In contrast to the above, all the files that are NOT unique to your app (shared libraries, Custom Elements HTML Imports, Bower components) should be placed under wwwroot/sys. This allows apps to be sufficient yet allow for resource sharing.

The next pages explain what's the benefit of all that - data sharing and screen sharing.

For example, there might be two applications that use <link rel="import" href="/sys/paper-input/paper-input.html">. Both of the apps host the static resource http://localhost:8080/sys/paper-input/paper-input.html. When requesting this URL, you are served by the last app that was started. Because the URLs are the same, there is no conflict of two Web Components loaded simultaneously. More about that in .

EnforceURINamespaces
http://localhost:8080/myapp/style.css
Using Web Components