Ruminating on the .well-known path in URLs

The .well-known path is a reserved directory at the root of a website’s domain (e.g., https://example.com/.well-known/). 

It serves as a standardized location for hosting metadata files that provide information about the domain or its services. The standard ensures that clients can reliably find these files without needing to guess their location or query the server in non-standard ways.

This also enhances interoperability as it ensures that clients (e.g., browsers, bots, or APIs) can find and parse metadata consistently across domains. It also supports automation as it enables automated systems to discover information like security policies, verification files, or protocol configurations.

Here are some widely used files and directories under /.well-known/ and their purposes:

security.txt

• Purpose: Provides contact information for reporting security vulnerabilities.
• Example: https://example.com/.well-known/security.txt
• Content: A text file with details like email addresses, encryption keys, or preferred reporting methods.
• Use Case: Security researchers use it to report vulnerabilities responsibly.

change-password

• Purpose: Indicates the URL where users can change their passwords.
• Example: https://example.com/.well-known/change-password
• Use Case: Improves user experience by standardizing password management endpoints.

For the Agent2Agent (A2A) Protocol, introduced by Google in April 2025, the .well-known path is used to host the Agent Card, a JSON metadata document that enables AI agents to discover and interact with each other in a standardized, secure, and interoperable way - e.g. https://example.com/.well-known/agent.json

#no-build for JS: Embracing the Era of Import Maps and HTTP/2

Complex build processes have dominated the web development world for years. JavaScript module bundling, transpiling, and management have become critical tasks for tools such as Webpack. However, what if there was an easier method? 

It is time for us to "un-learn" old tricks and rid ourselves of the baggage of old knowledge! Modern browsers support HTTP/2 and "import maps" for javascript modules and this is an absolute game changer!

In the past, web browsers had trouble comprehending contemporary JavaScript features and had trouble loading many small files quickly. Webpack and other build tools addressed these problems by:

• Bundling: Putting several JavaScript files together into a single, bigger file to cut down on HTTP requests.
• Transpiling:transforming current JavaScript syntax into an earlier iteration that works with an earlier browser.

Although these technologies were helpful to us, they increased complexity:

• Build Configuration: Build procedures frequently cause disruptions to the development workflow, necessitating continuous rebuilding and waiting. 
• Development Workflow Disruption: Build configurations can be time-consuming to set up and manage.

But all modern browsers (Chrome, Firefox, Safari, Edge) support HTTP/2 and "Import Maps" for JS modules. 

• Import maps enables us to use alias for full JS module paths - it is a method of creating a central registry that associates module names with their real locations is. This makes things clearer and more versatile by removing the requirement for you to write whole file paths in your code (across multiple files). 
• HTTP/2 is a more effective and rapid method of sending data across the internet. It makes it unnecessary to bundle files because browsers can handle several tiny files well. Instead of opening many connections to the server (like having many waiters running around), HTTP/2 uses one connection. Thus, multiple JS files can be downloaded concurrently, speeding up page load times.

Displaying PDF, Word, PPT docs on web pages

 If you need to display documents in PDF, Word or PPT formats on your web application, then the following JavaScript toolkit will come to your rescue. 

ViewerJS - https://viewerjs.org/

ViewerJS uses 2 other JS libraries behind the scenes - PDF.js (http://mozilla.github.io/pdf.js/) and WebODF (https://webodf.org/)

Any document that is following the Open Document Format (ODF) can be rendered using ViewerJS. All Office 365 files now follow the ODF format. 

Spring WebSocket STOMP tips and tricks

Recently we successfully implemented secure Websockets in one of our projects and learned a lot of tricks to get things working together. Given below are some tips that would help teams embarking on implementing WebSockets in their programs.

1)  Spring uses the STOMP protocol for Web Sockets. The other popular protocol for Web Sockets is WAMP, but Spring does not support it. Hence if you are using Spring, make sure that your Android, iOS and JS  libraries support STOMP.

2)  Spring websocket library by default also supports SockJS as a fall-back for web JS clients. If your use-case only entails supporting Android and iOS clients, then disable SockJS in your Spring configuration. It might happen that a use-case might work on SockJS on a web-client, but fail in native mobile code.

3) The default SockJS implementation of Spring, sends a server heartbeat header (char 'h') every 25 seconds to the clients. Hence there is no timeout on the socket connection for JS clients. But on mobile apps (pure STOMP), there is no heartbeat configured by default. Hence we have to explicitly set the heartbeat on the server OR on the client to keep the connection alive when idle. Otherwise, idle connections get dropped after 1 minute. Reference Links: https://stackoverflow.com/questions/28841505/spring-4-stomp-websockets-heartbeat
Sample server side code below.

4) One Android websocket library that works very well with Spring websockets is https://github.com/NaikSoftware/StompProtocolAndroid. But unfortunately, this library does not support heartbeats. Hence you have to explicitly send heartbeats using sample code like this - https://github.com/NaikSoftware/StompProtocolAndroid/issues/18.

5) On iOS, the following socket library worked very well with Spring websockets - https://github.com/rguldener/WebsocketStompKit. We faced an issue, where this library was throwing Array Index Range exceptions on server side heartbeat messages, but we made small changes in this library to skip process for heart-beat header messages.

6)  It is recommended to give the URL scheme as wss://, although we found that https:// was also working fine. If you have SockJS enabled on Spring, then please append the URL with /websocket, as you would get a exception stating invalid protocol up-gradation. Hence clients should subscribe to/{endpoint}/websocket. https://github.com/rstoyanchev/spring-websocket-portfolio/issues/14

7)  Both libraries also support sending headers during the CONNECT step. Very often, teams send the authorization token during the CONNECT step in the header, that can be used to authenticate the client. To access these headers on the server we need to access the Nativeheaders hashmap. Sample code - https://github.com/rsparkyc/WebSocketServer/blob/master/src/main/java/hello/ConnectionListener.java

  

Performance benefits of HTTP/2

The HTTP/2 protocol brings in a lot of benefits in terms of performance for modern web applications. To understand what benefits HTTP/2 brings, it is important to understand the limitations of HTTP/1.1  protocol.

The HTTP protocol only allows one 'outstanding' request per TCP connection - i.e. if a page is downloading 100 assets, only one request can be made per TCP connection. Browsers typically open 4-8 TCP connections per page to load the page faster (parallel requests), but this results in network congestion.

The HTTP/2 protocol is fully multiplexed - i.e. it allows multiple parallel requests/responses on the same TCP connection. It also compresses HTTP headers (reduce payload size) and is a binary protocol (not textual). The protocol also allows servers to proactively push responses directly to the browsers cache, thus avoiding HTTP requests.

The following links give an excellent explanation of the HTTP/2 protocol and its benefits.
https://http2.github.io/faq/
https://bagder.gitbooks.io/http2-explained/en/

The following site shows the performance of HTTP/2 compared to HTTP/1.1 when loading tons of images from the server - https://www.tunetheweb.com/performance-test-360/

There is another site - https://www.httpvshttps.com/ which states that HTTPS is faster than HTTP, but that is because HTTPS was using HTTP/2 by default in the background.

Building cool hybrid mobile apps - Lessons from Basecamp

Basecamp has successfully utilized hybrid techniques for building their iOS and Android apps. The following links are worth a perusal to understand the techniques they used.

https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content

https://signalvnoise.com/posts/3438-drawing-the-nativeweb-line-in-basecamp-for-iphone

https://signalvnoise.com/posts/3766-hybrid-how-we-took-basecamp-multi-platform-with-a-tiny-team


PhoneGap on its blog has made an interesting distinction between two types of Hybrid applications -

1. Web Hybrid: This is the default approach that PhoneGap takes. You package your apps as HMTL5/CSS3 and then run the app in a thin native web view container. All the UI controls are HTML or JavaScript controls.
2. Native Hybrid: In this approach, you build a native app and use native controls for navigation, menus, etc. But most of the content pages are HTML views rendered in a web view. The HTML content can come from the local store or the server. 

Ruminating on Less and Saas

CSS has been a boon to all web developers and allows for the clear separation of presentation from HTML markup. But CSS comes with it own limitations. For e.g.

• CSS does not have the ability to declare variables. Hence if you want a color to be used across multiple element types, you have to repeat the color. 
• CSS does not support nesting of properties. Hence we end up repeating the code again and again. 

To counter these limitations, there are new languages that have propped up that are known as 'CSS-Extension' languages. These languages support variables, nesting, etc. and make it super-easy to define themes in CSS.

Two of the most popular extension CSS languages are Less and Saas. These languages can be compiled into pure CSS language before being deployed to production. 

Ruminating on Server Side Push Techniques

The ability to push data from the server to the web browser has always been a pipe-dream for many web architects. Jotting down the various techniques that I used in the past and the new technologies on the horizon that would enable server side push.

• Long Polling (Comet): For the last few years, this technique has been most popular and is used behind the scenes by multiple ajax frameworks, such as DoJo, WebSphere Ajax toolkit, etc. The fundamental concept behind this technique is for the server to hold on to the request and not respond till there is some data. Once the data is ready, push the data to the browser as the HTTP Response. After getting the response, the client would again make a new poll request and wait for the response. Hence the term - "long polling". 
• Persistent Connections / Incomplete Response: Another technique in which the server never ends the response stream, but always keeps it open. There is a  special MIME type called multipart/x-mixed-replace, that is supported by most browsers expect IE :) This MIME type enables the server to keep the response stream open and send data in deltas to the browser.
• HTML 5 WebSockets: The new HTML 5 specification brings to us the power of WebSockets that enable full-duplex bidirectional data flow between browsers and servers. Very soon, we would have all browsers/servers supporting this. 

Validations - on client side or server side or both?

A few years back, many developers spend a lot of time in coding validation rules for web forms - both on the client side as well as the server side. This was very tedious and a few lazy developers would just write JavaScript validation and not write server-side validation code; thus exposing a serious security flaw in the application.
Good design warrants us to apply the principle of 'security in depth'.

But today, most of the web-based MVC frameworks have OOTB support for validations - both on the client side and server side; with minimal coding. The basic design concept is to annotate your domain objects with validation constraints and then let the framework create the JS code for client side validation and use the framework interceptors for server side validation.

Struts-2 is a popular java web MVC framework that supports this feature. In fact, there is a JSR specification on the usage of annotations for bean validations called JSR 303. Struts-2 also has a plug-in for OVal that implements JSR-303.

In the .NET world, ASP.NET MVC framework also supports this feature of annotation-based validations.

XSL transformations on the brower

Recently, I came across a web framework that was quite unconventional - the framework was performing XML transformations using XSLT on the browser. All web requests were directed to a legacy system that returned XML and this XML was directly sent to the brower. The browser had already loaded the necessary XSL, Javascript and does the XML -> HTML transformation.

There are certain pros and cons of this approach.
Advantages:

• Clear separation of markup/layout from content.
• Heavy XSL processing offloaded to the brower, brower JS code can check for brower compatibilities and spit out right markup code.

Disadvantages:

• All browsers do not support XSL in a standard way. Can be quite a pain to make the look-n-feel compatible with all browsers.
• Search engines/bots see raw XML, may not be able to interpret and understand.
• Disables progressive rendering. User won't see anything at all until entire stylesheet and data is loaded completely.
• XSL is pretty tough to master. Resource skill could become a potential bottleneck.
• Could run into scalability issues for large XML payloads. When processing XML files, XSLT must load the entire document into memory.

IMHO, although XSLT processing in-browser is fast compared to server side, it is still better if no transformation is required at all. There are tons of server side web-frameworks that can do the job better and faster.

Finding the geographical location of client web requests

Nowadays, we see many sites that show our geographical location the screen when we hit the page.
So how do the sites find out this information? Well, on the server side, we can obtain the IP address of the client (or the Internet provider proxy) from the request object.

From this IP address, we can query a database(typically csv files) and obtain the location information. The country information is free and available for download here.

For state and city information, U got to stuff out some moolah.. :)
More information can be found out here-
http://www.ip2location.com/faqs-ip-country.aspx